https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117320
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://sourceware.org/bugz
| |illa/show_bug.cgi?id=32313
--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Paul Eggert from comment #3)
> (In reply to Andrew Pinski from comment #1)
> > Does it happen in a full linked binary or just in the object file?
>
> The bug occurs in both, though of course I see different values for the
> backtrace_function address in the full linked binary:
>
> $ nm temacs | grep backtrace_function
> 0000000000293cd0 T backtrace_function
> 000000000006ee78 t backtrace_function.cold
> 000000000006ed5c t backtrace_function.part.0
> $ gdb -ex 'print backtrace_next' -ex 'print backtrace_function' temacs
> ...
> $1 = {union specbinding *(union specbinding *)} 0x293d70 <backtrace_next>
> $2 = {Lisp_Object (union specbinding *)} 0x6ed5c <backtrace_function>
Yes it looks like gdb can't handle the part.0 clone. (the .cold part is more
likely correctly handled since it is not exactly a clone but just part of the
original function). I do get the feeling even though GCC's debuging info could
be improved for the part.0 clone that gdb got confused on which is the full
function and which is the clone. I also suspect `b backtrace_function` will
work correctly and point to the locations, it is just printing of the value of
backtrace_function which is broken.
