SV: ARM Linux EABI: unwinding through a segfault handler

[mads_bn]

Nice work !

 

Some time ago I was in a project, where we would like to get more context in
syslog when e.g. SIGSEGV occurred (embedded Linux).

On x86 this was working fine, and I hope a change like this for ARM will
allow it to work here as well (as long as stack is still valid).

 

I don't have access to such an ARM setup currently.

Can somebody try if e.g. backtrace_symbols () will show where the offending
code was called from?

http://linux.die.net/man/3/backtrace_symbols 

 

Also I really like the idea to get this back into the mainstream version, so
we all will benefit from it in future ;-)

 

/Mads

 

Fra: Matthijs van Duin [via gcc]
[mailto:ml-node+s1065356n1191196...@n5.nabble.com] 
Sendt: 3. oktober 2015 22:42
Til: mads_bn 
Emne: Re: ARM Linux EABI: unwinding through a segfault handler

 

A shiny revised version of my unwind-through-signal code for ARM EABI: 

https://github.com/mvduin/arm-signal-unwind/

For actual unwinding it now uses sigreturn as a cleanup handler (after 
diddling the ucontext to make it land right onto a call to 
_Unwind_Resume), which means that all state should get properly 
restored by the kernel. 

Virtual unwinding still only restores core registers, but hopefully 
that isn't too big a problem in practice. 

A small test is included that confirms throwing exceptions out of 
SEGV, checks VFP is restored properly, and that returning normally 
from an async signal handler still works (my original patch accidently 
broke that). 

I'd finally like to take a moment to say this was hell to figure 
out this shit is really documented nowhere properly since it 
appears to be a magic blend of ARM EABI and IA64 C++ ABI (meaning 
neither documentation quite applies) and I had to plow through the 
innards of libgcc and libsupc++ to figure out how things *actually* 
work. Argh. 

Anyhow, it only took four years, but you can now throw 
NullPointerExceptions on ARM. Enjoy. ;-) 

Matthijs van Duin 



  _  

If you reply to this email, your message will be added to the discussion
below:

http://gcc.1065356.n5.nabble.com/ARM-Linux-EABI-unwinding-through-a-segfault
-handler-tp692287p1191196.html 

To unsubscribe from ARM Linux EABI: unwinding through a segfault handler,
click here
<http://gcc.1065356.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe
_by_code&node=692287&code=bWFkc2JuQG1haWwuZGt8NjkyMjg3fDIwNDQ1NTEzNzU=> .
 
<http://gcc.1065356.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewe
r&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNam
espace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.Nod
eNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emai
ls%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> NAML 





--
View this message in context: 
http://gcc.1065356.n5.nabble.com/SV-ARM-Linux-EABI-unwinding-through-a-segfault-handler-tp1191260.html
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: ARM Linux EABI: unwinding through a segfault handler

[mads_bn]

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).

http://www.eglibc.org/cgi-bin/viewvc.cgi/branches/eglibc-2_19/libc/ports/sysdeps/unix/sysv/linux/arm/sigrestorer.S?view=markup

  
https://sourceware.org/git/?p=glibc.git;a=history;f=sysdeps/unix/sysv/linux/arm/sigrestorer.S;h=71f9e25804bedb58cb06396834e8cea05dedc191;hb=refs/heads/master

   

arm7$ ./test
# backtrace before signal raised
backtrace() returned 6 addresses
libdemo.so(_Z11doBacktracePKci+0x44) [0xb6f3ae38]
libdemo.so(_Z2f3v+0x1c) [0xb6f3af24]
libdemo.so(_Z2f2v+0x20) [0xb6f3af54]
libdemo.so(_Z2f1v+0x28) [0xb6f3af8c]
./test() [0x8740]
/lib/libc.so.6(__libc_start_main+0x110) [0x444b7ea8]
abort
# backtrace after signal raised, signal_handler dumps backtrace and raise
SIGQUIT to core dump
--8< Stack 8<--
Error: signal 6:
libdemo.so(_ZN14doBacktraceEi+0x30)[0xb6f3b4f8]
libdemo.so(_ZN14signal_handlerEi+0x134)[0xb6f3b3b4]
/lib/libc.so.6(__default_sa_restorer_v2+0x0)[0x444ce1d0]
/lib/libc.so.6(gsignal+0x3c)[0x444ccf28]
--8<---8<--
Quit (core dumped)
===
$ gdb test core
...
Program terminated with signal 3, Quit.
#0  0x444ccf28 in raise () from /lib/libc.so.6
(gdb) bt
#0  0x444ccf28 in raise () from /lib/libc.so.6
#1  0xb6f3b488 in signal_handler (sig=6) at mysignalhandler.cpp:176
#2  
#3  0x444ccf28 in raise () from /lib/libc.so.6
#4  0x444d09a8 in abort () from /lib/libc.so.6
#5  0xb6f3afc0 in f1 () at foo.cpp:57
#6  0x8740 in main ()



--
View this message in context: 
http://gcc.1065356.n5.nabble.com/ARM-Linux-EABI-unwinding-through-a-segfault-handler-tp692287p1117716.html
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: ARM Linux EABI: unwinding through a segfault handler

[mads_bn]

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).

http://www.eglibc.org/cgi-bin/viewvc.cgi/branches/eglibc-2_19/libc/ports/sysdeps/unix/sysv/linux/arm/sigrestorer.S?view=markup

  
https://sourceware.org/git/?p=glibc.git;a=history;f=sysdeps/unix/sysv/linux/arm/sigrestorer.S;h=71f9e25804bedb58cb06396834e8cea05dedc191;hb=refs/heads/master

   

arm7$ ./test
# backtrace before signal raised
backtrace() returned 6 addresses
libdemo.so(_Z11doBacktracePKci+0x44) [0xb6f3ae38]
libdemo.so(_Z2f3v+0x1c) [0xb6f3af24]
libdemo.so(_Z2f2v+0x20) [0xb6f3af54]
libdemo.so(_Z2f1v+0x28) [0xb6f3af8c]
./test() [0x8740]
/lib/libc.so.6(__libc_start_main+0x110) [0x444b7ea8]
abort
# backtrace after signal raised, signal_handler dumps backtrace and raise
SIGQUIT to core dump
--8< Stack 8<--
Error: signal 6:
libdemo.so(_ZN14doBacktraceEi+0x30)[0xb6f3b4f8]
libdemo.so(_ZN14signal_handlerEi+0x134)[0xb6f3b3b4]
/lib/libc.so.6(__default_sa_restorer_v2+0x0)[0x444ce1d0]
/lib/libc.so.6(gsignal+0x3c)[0x444ccf28]
--8<---8<--
Quit (core dumped)
===
$ gdb test core
...
Program terminated with signal 3, Quit.
#0  0x444ccf28 in raise () from /lib/libc.so.6
(gdb) bt
#0  0x444ccf28 in raise () from /lib/libc.so.6
#1  0xb6f3b488 in signal_handler (sig=6) at mysignalhandler.cpp:176
#2  
#3  0x444ccf28 in raise () from /lib/libc.so.6
#4  0x444d09a8 in abort () from /lib/libc.so.6
#5  0xb6f3afc0 in f1 () at foo.cpp:57
#6  0x8740 in main ()



--
View this message in context: 
http://gcc.1065356.n5.nabble.com/ARM-Linux-EABI-unwinding-through-a-segfault-handler-tp692287p1117717.html
Sent from the gcc - Dev mailing list archive at Nabble.com.