ARM Linux EABI: unwinding through a segfault handler

Tue Feb 3 22:41:00 GMT 2015

Paul, do you know of any progress on this since 2011?

I cannot find any attempt to use your suggested ".personality
__gnu_personality_sigframe" in prologue for "__default_sa_restorer_v2".
I still need to learn more about this syntax...
I'm not building the glibc myself, but can probably let a friend try it if
we believe it is the right fix.

We hope to be able to make some poor man's backtrace's in syslog, when fatal
signals occurs in embedded systems (SIGSEGV, abort->SIGABRT etc).
This was quite useful on x86 targets in the past.

We are currently upgrading from EGLIBC 2.16 to 2.19 (yocto builds) and I
also tried to browse the regular GLIBC head.
With EGLIBC 2.16 I made a small test program and the backtrace always
stopped at gsignal(),
but if my signal_handler then triggered a coredump using raise(SIGQUIT) then
gdb was able to backtrace beyond the signal handler (see below).

arm7$ ./test
# backtrace before signal raised
backtrace() returned 6 addresses [0xb6f3ae38] [0xb6f3af24] [0xb6f3af54] [0xb6f3af8c]
./test() [0x8740]
/lib/ [0x444b7ea8]
# backtrace after signal raised, signal_handler dumps backtrace and raise
SIGQUIT to core dump
--8<-------------------- Stack --------------------8<--
Error: signal 6:[0xb6f3b4f8][0xb6f3b3b4]
Quit (core dumped)
$ gdb test core
Program terminated with signal 3, Quit.
#0  0x444ccf28 in raise () from /lib/
(gdb) bt
#0  0x444ccf28 in raise () from /lib/
#1  0xb6f3b488 in signal_handler (sig=6) at mysignalhandler.cpp:176
#2  <signal handler called>
#3  0x444ccf28 in raise () from /lib/
#4  0x444d09a8 in abort () from /lib/
#5  0xb6f3afc0 in f1 () at foo.cpp:57
#6  0x00008740 in main ()

View this message in context:
Sent from the gcc - Dev mailing list archive at

More information about the Gcc mailing list