GNU bug report logs - #65455
30.0.50; Disassemble: error with "free-standing" native compiled function

Previous Next

Package: emacs;

Reported by: Gerd Möllmann <gerd.moellmann <at> gmail.com>

Date: Tue, 22 Aug 2023 13:18:02 UTC

Severity: normal

Found in version 30.0.50

Fixed in version 30.1

Done: Gerd Möllmann <gerd.moellmann <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Andrea Corallo <acorallo <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 65455 <at> debbugs.gnu.org
Subject: bug#65455: 30.0.50; Disassemble: error with "free-standing" native compiled function
Date: Sun, 27 Aug 2023 14:04:57 -0400
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Andrea Corallo <acorallo <at> gnu.org>
>> Cc: gerd.moellmann <at> gmail.com,  65455 <at> debbugs.gnu.org
>> Date: Sun, 27 Aug 2023 10:43:30 -0400
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> [...]
>> 
>> >> > Also, Andrea, why does
>> >> >
>> >> >   (native-compile 'foo SOME-FILE)
>> >> >
>> >> > signals an error?  I thought it should write the results of
>> >> > native-compilation to SOME-FILE, no?
>> >> 
>> >> Loos like a bug, if SOME-FILE is absolute it just works.  The fix look
>> >> trivial, I'll just test it a bit before pushing it.
>> >
>> > Thanks.
>> 
>> Fix pushed into 29 as e7ac50a1539.
>
> Thanks, now '(native-compile 'foo SOME-FILE)' succeeds, but
> disassemble signals an error:
>
>   (defun foo (a b)
>     (list a b))
>
>   (native-compile 'foo "foo.eln")
>   (disassemble 'foo)
>
>   Debugger entered--Lisp error: (search-failed "^.*<F666f6f_foo_0>:")
>     re-search-forward("^.*<F666f6f_foo_0>:")
>     disassemble-internal(foo 0 t)
>     disassemble(foo)
>     (progn (disassemble 'foo))
>     elisp--eval-last-sexp(t)
>     eval-last-sexp(t)
>     eval-print-last-sexp(nil)
>     funcall-interactively(eval-print-last-sexp nil)
>     command-execute(eval-print-last-sexp)
>
> I get a similar error even if I disassemble a function from a
> preloaded Lisp package, for example file-relative-name.
>
> It looks like a Windows-specific issue: the symbols produced by
> objdump here have a leading underscore:
>
>   6b341400 <_F666f6f_foo_0>:
>   6b341400:	57                   	push   %edi
>   6b341401:	56                   	push   %esi
>   6b341402:	53                   	push   %ebx
>
> So I think the regexp should be "^.*<_?F666f6f_foo_0>:" instead.

Yep agree, I think this bug was unrelated, could you please check that
ea5fd6c96bc works for you on Windows?

Thanks!

  Andrea




This bug report was last modified 1 year and 270 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.