Re: eassert always aborts in eval.c in an optimized build

[Eli Zaretskii]

> Date: Sun, 27 Oct 2024 10:57:21 -0700
> Cc: emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> On 2024-10-27 01:50, Eli Zaretskii wrote:
> > Something is wrong with our definition/use of eassert in eval.c when
> > Emacs is compiled with optimizations and with --enable-checking: all
> > the functions in eval.c that assert pdl->kind's value are compiled
> > into code that always aborts.
> 
> A quick look suggests that although the actual code is fine, GDB is 
> confused and its "disassemble" and other commands think that the symbol 
> "backtrace_function" stands for the address of just part of the 
> backtrace_function code, not the address of the function's first 
> instruction.

But then why does xbacktrace always abort?  Are you saying it calls
the part that aborts?

> If my guess is right, if you try to debug Emacs with GDB and use 
> xbacktrace or similar commands, things will go haywire. You'll see 
> symptoms like this:
> 
> (gdb) p backtrace_function
> $1 = {Lisp_Object (union specbinding *)} 0x6ed5c <backtrace_function>
> 
> ... whereas the shell command "nm emacs | grep backtrace_function" 
> outputs this:
> 
> 0000000000293cd0 T backtrace_function
> 000000000006ee78 t backtrace_function.cold
> 000000000006ed5c t backtrace_function.part.0

I see the first and the last of these 3 lines; mo "cold" part.

> ... and we can see that GDB has the wrong "backtrace_function".
> 
> Does this match the symptoms you're observing?

Sounds like that, yes.

> If my guess is right, GDB should be fixed, and also we should look into 
> patching Emacs to work around the GDB bug.

I see this with GDB 12.1 on GNU/Linux and with GDB 15.1 on MS-Windows,
so I'm guessing fixing GDB will not be easy, and there will be many
un-fixed GDB versions around even after GDB is fixed.  We should work
around this in Emacs regardless.

Thanks.