[Bug libgcc/113803] New: libgcc unwinder stops at calls to null function pointer on some targets

[Bug libgcc/113803] New: libgcc unwinder stops at calls to null function pointer on some targets

[fw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113803

            Bug ID: 113803
           Summary: libgcc unwinder stops at calls to null function
                    pointer on some targets
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libgcc
          Assignee: unassigned at gcc dot gnu.org
          Reporter: fw at gcc dot gnu.org
  Target Milestone: ---

Originally reported as a glibc bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=31349

If a null pointer is called, the backtrace stops at the signal frame on most
GNU/Linux architectures (tried aarch64, s390x, x86-64), presumably due to the
null address in the signal context. On powerpc64le, backtracing continues as
expected. This does not seem to be related to use of the sigreturn trampoline
from the vDSO.

[Bug libgcc/113803] libgcc unwinder stops at calls to null function pointer on some targets

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113803

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Hmm, I thought I saw this bug report before ...

[Bug libgcc/113803] libgcc unwinder stops at calls to null function pointer on some targets

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113803

--- Comment #2 from Andreas Schwab <schwab@linux-m68k.org> ---
  if (context->ra == 0)
    return _URC_END_OF_STACK;

[Bug libgcc/113803] libgcc unwinder stops at calls to null function pointer on some targets

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113803

--- Comment #3 from Andreas Schwab <schwab@linux-m68k.org> ---
Since DWARF unwinding depends on the unwind info associated with the return
address, I don't think anything can be done about that.  On powerpc, a
backtrace can be constructed from link address that connects the stack frames
together, but that works only before glibc commit 82fd7314c7.

[Bug libgcc/113803] libgcc unwinder stops at calls to null function pointer on some targets

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113803

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
The return address should be still on the stack for most archs, unless we run
into zero by "overflowing" the IP, of course.

[Bug libgcc/113803] libgcc unwinder stops at calls to null function pointer on some targets

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113803

--- Comment #5 from Andreas Schwab <schwab@linux-m68k.org> ---
The return address is coming from the signal frame, and it is zero here due the
null pointer call.

[Bug libgcc/113803] libgcc unwinder stops at calls to null function pointer on some targets

[fw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113803

--- Comment #6 from Florian Weimer <fw at gcc dot gnu.org> ---
I we knew that the last successfully executed instruction was an indirect call
or branch (assumed to be tail call), we could use the return address at the top
of the stack, for architectures where call instructions push the return address
onto the stack. This is probably what GDB is doing.

The issue is of course that if the fault was caused by something else, we
should instead the program counter in the signal frame to continue unwinding.
Maybe we could special-case this for PC == 0, which is obviously invalid.

[Bug libgcc/113803] libgcc unwinder stops at calls to null function pointer on some targets

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113803

--- Comment #7 from Andreas Schwab <schwab@linux-m68k.org> ---
Actually, the null return address is coming from the unwind information of
__return_rt, which is just a normal function for the unwinder.  gdb has special
knowlege to detect it as a signal trampoline (based on the function name).