This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

SV: ARM Linux EABI: unwinding through a segfault handler


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+s1065356n1191196h83@n5.nabble.com] 
Sendt: 3. oktober 2015 22:42
Til: mads_bn <madsbn@mail.dk>
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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]