https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113803
--- Comment #7 from Andreas Schwab ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113803
--- Comment #6 from Florian Weimer ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113803
--- Comment #5 from Andreas Schwab ---
The return address is coming from the signal frame, and it is zero here due the
null pointer call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113803
--- Comment #4 from Richard Biener ---
The return address should be still on the stack for most archs, unless we run
into zero by "overflowing" the IP, of course.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113803
--- Comment #3 from Andreas Schwab ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113803
--- Comment #2 from Andreas Schwab ---
if (context->ra == 0)
return _URC_END_OF_STACK;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113803
--- Comment #1 from Andrew Pinski ---
Hmm, I thought I saw this bug report before ...
