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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 65455 in the body.
You can then email your comments to 65455 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; Disassemble: error with "free-standing" native compiled
 function
Date: Tue, 22 Aug 2023 15:17:21 +0200

In *scratch*, evaluate

(defun foo (a b)
  (list a b))

(native-compile 'foo)
(disassemble 'foo)

This gives an error in disass.el, around line 98 that a re-search fails,
but the real error might be that, in the lines above, objdump is called
on a file that does not exist.

Workaround is to save the function to a file, native-compile that file,
and load the resulting .eln.  Then the disassemble works as expected.

In GNU Emacs 30.0.50 (build 1, aarch64-apple-darwin22.6.0, NS
 appkit-2299.70 Version 13.5 (Build 22G74)) of 2023-08-22 built on
 Mini.fritz.box
Repository revision: fe6009795211844ae2deda602c197cb57265eb64
Repository branch: scratch/pkg
Windowing system distributor 'Apple', version 10.3.2299
System Description:  macOS 13.5

Configured using:
 'configure --cache-file /Users/gerd/tmp/config.cache.pkg
 --with-native-compilation --disable-silent-rules 'CFLAGS=-g -O0''

Message #8 received at 65455 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>, Andrea
 Corallo <acorallo <at> gnu.org>
Cc: 65455 <at> debbugs.gnu.org
Subject: Re: bug#65455: 30.0.50;
 Disassemble: error with "free-standing" native compiled function
Date: Tue, 22 Aug 2023 16:29:25 +0300

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Date: Tue, 22 Aug 2023 15:17:21 +0200
> 
> In *scratch*, evaluate
> 
> (defun foo (a b)
>   (list a b))
> 
> (native-compile 'foo)
> (disassemble 'foo)
> 
> This gives an error in disass.el, around line 98 that a re-search fails,
> but the real error might be that, in the lines above, objdump is called
> on a file that does not exist.
> 
> Workaround is to save the function to a file, native-compile that file,
> and load the resulting .eln.  Then the disassemble works as expected.

What happens if you do

  (native-compile 'foo "foo.eln")

instead?

Adding Andrea.

Message #11 received at 65455 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 65455 <at> debbugs.gnu.org, Andrea Corallo <acorallo <at> gnu.org>
Subject: Re: bug#65455: 30.0.50; Disassemble: error with "free-standing"
 native compiled function
Date: Tue, 22 Aug 2023 15:41:40 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> What happens if you do
>
>   (native-compile 'foo "foo.eln")
>
> instead?
>
> Adding Andrea.

Ok. I did

(fmakunbound 'foo)
(defun foo (a b)
  (list a b))
(native-compile 'foo "foo.eln")

That resulted in an error, with *Messages* containing

comp--native-compile: Native compiler error: foo, "Compiling foo.eln...
Wrong type argument: stringp, nil

Error: wrong-type-argument (stringp nil)
  mapbacktrace(#f(compiled-function (evald func args flags) #<bytecode -0x1ffb7762e512f81>))
  debug-early-backtrace()
  debug-early(error (wrong-type-argument stringp nil))
  file-exists-p(nil)
  comp-compile-ctxt-to-file(\"foo.eln\")
  comp-final1()
  load-with-code-conversion(\"/private/var/folders/1d/k_6t25f94sl83szqbf8gpkrh0000gn/T/emacs-int-comp-foo-e1cmnO.el\" \"/private/var/folders/1d/k_6t25f94sl83szqbf8gpkrh0000gn/T/emacs-int-comp-foo-e1cmnO.el\" nil t)
  command-line-1((\"-l\" \"/var/folders/1d/k_6t25f94sl83szqbf8gpkrh0000gn/T/emacs-int-comp-foo-e1cmnO.el\"))
  command-line()
  normal-top-level()

Message #14 received at 65455 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 65455 <at> debbugs.gnu.org, acorallo <at> gnu.org
Subject: Re: bug#65455: 30.0.50; Disassemble: error with "free-standing"
 native compiled function
Date: Tue, 22 Aug 2023 18:39:05 +0300

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: Andrea Corallo <acorallo <at> gnu.org>,  65455 <at> debbugs.gnu.org
> Date: Tue, 22 Aug 2023 15:41:40 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > What happens if you do
> >
> >   (native-compile 'foo "foo.eln")
> >
> > instead?
> >
> > Adding Andrea.
> 
> Ok. I did
> 
> (fmakunbound 'foo)
> (defun foo (a b)
>   (list a b))
> (native-compile 'foo "foo.eln")
> 
> That resulted in an error, with *Messages* containing
> 
> comp--native-compile: Native compiler error: foo, "Compiling foo.eln...
> Wrong type argument: stringp, nil

Let's wait for Andrea to chime in.  Maybe I misunderstood the intended
way of calling that function or what exactly its 2nd argument is.

Message #17 received at 65455 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <acorallo <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 65455 <at> debbugs.gnu.org
Subject: Re: bug#65455: 30.0.50; Disassemble: error with "free-standing"
 native compiled function
Date: Fri, 25 Aug 2023 04:11:48 -0400

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

> In *scratch*, evaluate
>
> (defun foo (a b)
>   (list a b))
>
> (native-compile 'foo)
> (disassemble 'foo)
>
> This gives an error in disass.el, around line 98 that a re-search fails,
> but the real error might be that, in the lines above, objdump is called
> on a file that does not exist.
>
> Workaround is to save the function to a file, native-compile that file,
> and load the resulting .eln.  Then the disassemble works as expected.
>
> In GNU Emacs 30.0.50 (build 1, aarch64-apple-darwin22.6.0, NS
>  appkit-2299.70 Version 13.5 (Build 22G74)) of 2023-08-22 built on
>  Mini.fritz.box
> Repository revision: fe6009795211844ae2deda602c197cb57265eb64
> Repository branch: scratch/pkg
> Windowing system distributor 'Apple', version 10.3.2299
> System Description:  macOS 13.5
>
> Configured using:
>  'configure --cache-file /Users/gerd/tmp/config.cache.pkg
>  --with-native-compilation --disable-silent-rules 'CFLAGS=-g -O0''

Hello all,

okay so the issue is the following, when we try to disassemble the
function we fail as the temporary eln file (that was created in /tmp)
just after being loaded is deleted.  I believe thei behaviour was
introduced by ef6059cb8325 with the intent of not leaving temporary
files around.

Infact "normal disassemble" of functions belonging to .el files it's
still functional and this bug affects only functions not related to a
specific source file.

I think we have 3 options:

1- Give up on the disassemble on this specific case

2- Do not remove the temporary eln file in /tmp and wait for the OS to
   do it for us.

3- Keep a list of temporary eln files we want to clean-up when Emacs
   exits.

Bests

  Andrea

Message #20 received at 65455 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <acorallo <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 65455 <at> debbugs.gnu.org
Subject: Re: bug#65455: 30.0.50;
 Disassemble: error with "free-standing" native compiled function
Date: Fri, 25 Aug 2023 13:30:25 +0300

> Cc: 65455 <at> debbugs.gnu.org
> From: Andrea Corallo <acorallo <at> gnu.org>
> Date: Fri, 25 Aug 2023 04:11:48 -0400
> 
> 1- Give up on the disassemble on this specific case
> 
> 2- Do not remove the temporary eln file in /tmp and wait for the OS to
>    do it for us.
> 
> 3- Keep a list of temporary eln files we want to clean-up when Emacs
>    exits.

None of the above sounds a good idea to me.  How about a special
disassemble-native function, which will keep the temporary file until
after the disassembly, and then delete it?  Gerd, would that be good
enough?

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?

Message #23 received at 65455 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#65455: 30.0.50; Disassemble: error with "free-standing"
 native compiled function
Date: Fri, 25 Aug 2023 07:43:07 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Cc: 65455 <at> debbugs.gnu.org
>> From: Andrea Corallo <acorallo <at> gnu.org>
>> Date: Fri, 25 Aug 2023 04:11:48 -0400
>> 
>> 1- Give up on the disassemble on this specific case
>> 
>> 2- Do not remove the temporary eln file in /tmp and wait for the OS to
>>    do it for us.
>> 
>> 3- Keep a list of temporary eln files we want to clean-up when Emacs
>>    exits.
>
> None of the above sounds a good idea to me.  How about a special
> disassemble-native function, which will keep the temporary file until
> after the disassembly, and then delete it?  Gerd, would that be good
> enough?

Mmmh, I'm not sure I undestand, how can disassemble-native keep the
temporary file if this was deleted just after it was compiled and
loaded?

> 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

  Andrea

Message #26 received at 65455 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <acorallo <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 65455 <at> debbugs.gnu.org
Subject: Re: bug#65455: 30.0.50; Disassemble: error with "free-standing"
 native compiled function
Date: Fri, 25 Aug 2023 14:47:31 +0300

> From: Andrea Corallo <acorallo <at> gnu.org>
> Cc: gerd.moellmann <at> gmail.com,  65455 <at> debbugs.gnu.org
> Date: Fri, 25 Aug 2023 07:43:07 -0400
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> Cc: 65455 <at> debbugs.gnu.org
> >> From: Andrea Corallo <acorallo <at> gnu.org>
> >> Date: Fri, 25 Aug 2023 04:11:48 -0400
> >> 
> >> 1- Give up on the disassemble on this specific case
> >> 
> >> 2- Do not remove the temporary eln file in /tmp and wait for the OS to
> >>    do it for us.
> >> 
> >> 3- Keep a list of temporary eln files we want to clean-up when Emacs
> >>    exits.
> >
> > None of the above sounds a good idea to me.  How about a special
> > disassemble-native function, which will keep the temporary file until
> > after the disassembly, and then delete it?  Gerd, would that be good
> > enough?
> 
> Mmmh, I'm not sure I undestand, how can disassemble-native keep the
> temporary file if this was deleted just after it was compiled and
> loaded?

By instructing the compilation not to delete it, and then deleting it
after disassembly, I guess?

> > 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.

Message #29 received at 65455 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#65455: 30.0.50; Disassemble: error with "free-standing"
 native compiled function
Date: Fri, 25 Aug 2023 07:52:06 -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: Fri, 25 Aug 2023 07:43:07 -0400
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> Cc: 65455 <at> debbugs.gnu.org
>> >> From: Andrea Corallo <acorallo <at> gnu.org>
>> >> Date: Fri, 25 Aug 2023 04:11:48 -0400
>> >> 
>> >> 1- Give up on the disassemble on this specific case
>> >> 
>> >> 2- Do not remove the temporary eln file in /tmp and wait for the OS to
>> >>    do it for us.
>> >> 
>> >> 3- Keep a list of temporary eln files we want to clean-up when Emacs
>> >>    exits.
>> >
>> > None of the above sounds a good idea to me.  How about a special
>> > disassemble-native function, which will keep the temporary file until
>> > after the disassembly, and then delete it?  Gerd, would that be good
>> > enough?
>> 
>> Mmmh, I'm not sure I undestand, how can disassemble-native keep the
>> temporary file if this was deleted just after it was compiled and
>> loaded?
>
> By instructing the compilation not to delete it, and then deleting it
> after disassembly, I guess?

Okay but what if the file is never disassembled?  What if it's
disassembled more than once?  Isn't 3 simpler at this stage?

Thanks

  Andrea

Message #32 received at 65455 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <acorallo <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 65455 <at> debbugs.gnu.org
Subject: Re: bug#65455: 30.0.50; Disassemble: error with "free-standing"
 native compiled function
Date: Fri, 25 Aug 2023 16:01:53 +0300

> From: Andrea Corallo <acorallo <at> gnu.org>
> Cc: gerd.moellmann <at> gmail.com,  65455 <at> debbugs.gnu.org
> Date: Fri, 25 Aug 2023 07:52:06 -0400
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> > None of the above sounds a good idea to me.  How about a special
> >> > disassemble-native function, which will keep the temporary file until
> >> > after the disassembly, and then delete it?  Gerd, would that be good
> >> > enough?
> >> 
> >> Mmmh, I'm not sure I undestand, how can disassemble-native keep the
> >> temporary file if this was deleted just after it was compiled and
> >> loaded?
> >
> > By instructing the compilation not to delete it, and then deleting it
> > after disassembly, I guess?
> 
> Okay but what if the file is never disassembled?  What if it's
> disassembled more than once?  Isn't 3 simpler at this stage?

I think we are mis-communicating.  What I meant is something like this:

  . add a new optional argument to native-compile that would prevent
    it from deleting the .eln file
  . add a new function disassemble-native, which will call
    native-compile with this new argument, perform disassembly, and
    then delete the file

Message #35 received at 65455 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#65455: 30.0.50; Disassemble: error with "free-standing"
 native compiled function
Date: Fri, 25 Aug 2023 10:11:58 -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: Fri, 25 Aug 2023 07:52:06 -0400
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> > None of the above sounds a good idea to me.  How about a special
>> >> > disassemble-native function, which will keep the temporary file until
>> >> > after the disassembly, and then delete it?  Gerd, would that be good
>> >> > enough?
>> >> 
>> >> Mmmh, I'm not sure I undestand, how can disassemble-native keep the
>> >> temporary file if this was deleted just after it was compiled and
>> >> loaded?
>> >
>> > By instructing the compilation not to delete it, and then deleting it
>> > after disassembly, I guess?
>> 
>> Okay but what if the file is never disassembled?  What if it's
>> disassembled more than once?  Isn't 3 simpler at this stage?
>
> I think we are mis-communicating.  What I meant is something like this:
>
>   . add a new optional argument to native-compile that would prevent
>     it from deleting the .eln file
>   . add a new function disassemble-native, which will call
>     native-compile with this new argument, perform disassembly, and
>     then delete the file

I see thanks for clarifying.

I'm not sure I like this option, reason is that I typically want to see
the disassembly of the already installed function rather than triggering
a new compilation.  Any change in the environment can lead to a
different output so I think is important to inspect what was produced
when it was commanded, no?

Bests

  Andrea

Message #38 received at 65455 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <acorallo <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 65455 <at> debbugs.gnu.org
Subject: Re: bug#65455: 30.0.50; Disassemble: error with "free-standing"
 native compiled function
Date: Fri, 25 Aug 2023 17:56:59 +0300

> From: Andrea Corallo <acorallo <at> gnu.org>
> Cc: gerd.moellmann <at> gmail.com,  65455 <at> debbugs.gnu.org
> Date: Fri, 25 Aug 2023 10:11:58 -0400
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > I think we are mis-communicating.  What I meant is something like this:
> >
> >   . add a new optional argument to native-compile that would prevent
> >     it from deleting the .eln file
> >   . add a new function disassemble-native, which will call
> >     native-compile with this new argument, perform disassembly, and
> >     then delete the file
> 
> I see thanks for clarifying.
> 
> I'm not sure I like this option, reason is that I typically want to see
> the disassembly of the already installed function rather than triggering
> a new compilation.  Any change in the environment can lead to a
> different output so I think is important to inspect what was produced
> when it was commanded, no?

If we want to support changes in the environment, I think it would be
an impossibly high bar for such a minor feature.

So perhaps the following would be enough:

  . find the source .el file of the compiled function
  . compile it into a temporary file and disassemble the result
  . delete the compiled temporary file

Out of the alternatives you proposed only #3 is to some extent
acceptable, but it is too complicated, IMO.

Message #41 received at 65455 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#65455: 30.0.50; Disassemble: error with "free-standing"
 native compiled function
Date: Sun, 27 Aug 2023 09:34:47 -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: Fri, 25 Aug 2023 10:11:58 -0400
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > I think we are mis-communicating.  What I meant is something like this:
>> >
>> >   . add a new optional argument to native-compile that would prevent
>> >     it from deleting the .eln file
>> >   . add a new function disassemble-native, which will call
>> >     native-compile with this new argument, perform disassembly, and
>> >     then delete the file
>> 
>> I see thanks for clarifying.
>> 
>> I'm not sure I like this option, reason is that I typically want to see
>> the disassembly of the already installed function rather than triggering
>> a new compilation.  Any change in the environment can lead to a
>> different output so I think is important to inspect what was produced
>> when it was commanded, no?
>
> If we want to support changes in the environment, I think it would be
> an impossibly high bar for such a minor feature.
>
> So perhaps the following would be enough:
>
>   . find the source .el file of the compiled function

That's the tricky part, this bug report is about compiling and
disassembling a function with no source file:

(defun foo (a b)      
  (list a b))         
                      
(native-compile 'foo) 
(disassemble 'foo)

In the moment we compile foo we loose it's original definition and we
can compile it twice :/

Thanks

  Andrea

Message #44 received at 65455 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <acorallo <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 65455 <at> debbugs.gnu.org
Subject: Re: bug#65455: 30.0.50; Disassemble: error with "free-standing"
 native compiled function
Date: Sun, 27 Aug 2023 16:40:07 +0300

> From: Andrea Corallo <acorallo <at> gnu.org>
> Cc: gerd.moellmann <at> gmail.com,  65455 <at> debbugs.gnu.org
> Date: Sun, 27 Aug 2023 09:34:47 -0400
> 
> > If we want to support changes in the environment, I think it would be
> > an impossibly high bar for such a minor feature.
> >
> > So perhaps the following would be enough:
> >
> >   . find the source .el file of the compiled function
> 
> That's the tricky part, this bug report is about compiling and
> disassembling a function with no source file:

Yes.  I'm saying we should not try to support that case, because it's
too hard.

Message #47 received at 65455 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#65455: 30.0.50; Disassemble: error with "free-standing"
 native compiled function
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.

Bests

  Andrea

Message #50 received at 65455 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#65455: 30.0.50; Disassemble: error with "free-standing"
 native compiled function
Date: Sun, 27 Aug 2023 11:41:46 -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 09:34:47 -0400
>>
>> > If we want to support changes in the environment, I think it would be
>> > an impossibly high bar for such a minor feature.
>> >
>> > So perhaps the following would be enough:
>> >
>> >   . find the source .el file of the compiled function
>>
>> That's the tricky part, this bug report is about compiling and
>> disassembling a function with no source file:
>
> Yes.  I'm saying we should not try to support that case, because it's
> too hard.

Okay,

I pushed 91d2d8439bb into 29, please have a look if the working of the
error is okay.

Thanks

  Andrea

Message #53 received at 65455 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <acorallo <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 65455 <at> debbugs.gnu.org
Subject: Re: bug#65455: 30.0.50; Disassemble: error with "free-standing"
 native compiled function
Date: Sun, 27 Aug 2023 19:21:01 +0300

> 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.

Message #56 received at 65455 <at> debbugs.gnu.org (full text, mbox):

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: Re: 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

Message #59 received at 65455 <at> debbugs.gnu.org (full text, mbox):

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

> From: Andrea Corallo <acorallo <at> gnu.org>
> Cc: gerd.moellmann <at> gmail.com,  65455 <at> debbugs.gnu.org
> Date: Sun, 27 Aug 2023 14:04:57 -0400
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > 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?

Works, thanks.

Message #62 received at 65455 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 65455 <at> debbugs.gnu.org, Andrea Corallo <acorallo <at> gnu.org>
Subject: Re: bug#65455: 30.0.50; Disassemble: error with "free-standing"
 native compiled function
Date: Thu, 26 Oct 2023 08:53:24 +0200

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 14:04:57 -0400
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > 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?
>
> Works, thanks.

I thinks this has been fixed, so I'm closing it.

Previous Next

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