Blair Barnett writes: > Thanks. So if I interpret your response correctly, even if I apply > the patch to the 4.1.1 EABI gcc compiler code, I won't get the > 3.3.2 non-EABI gcc result (i.e., I was able to unwind the backtrace > across a signal handler frame using the 3.3.2 compiler)? That would be my guess. But, to be honest, I have absolutely no idea how 3.3.2 non-EABI backtraces() managed to unwind through a sighandler frame. If I were you I'd go with my first suggestion: it's easy to try. Andrew. > ----- Original Message ---- > From: Andrew Haley <aph-gcc@xxxxxxxxxxxxxxxxxxx> > To: Blair Barnett <blairbarnett@xxxxxxxxxxxxx> > Cc: David Daney <ddaney@xxxxxxxxxx>; gcc-help mailing list <gcc-help@xxxxxxxxxxx> > Sent: Wednesday, August 29, 2007 11:59:18 AM > Subject: Re: Solution sought to GCC 4.1.1 backtrace problem > > Blair Barnett writes: > > > We're using the EABI extensions, so I think we're safe there. We're > > trying the patch now. However, being unfamiliar with this code, I'm > > wondering how it works, since I don't see any calls to the new > > functions in the patch: > > http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01388.html > > > > Thanks for all the help! There may be light at the end of this tunnel! > > For _Unwind_Backtrace to work, all code must be compiled with > -fexceptions. > > Also, if you want to unwind through a signal handler you'll need some > code that recognizes a signal frame and unwinds through it. There is > not yet any such thing for ARM EABI. There's an example of how you do > this at x86_64_fallback_frame_state() in gcc/config/i386/linux-unwind.h. > > This kind of thing is hard to write: I understand exactly how it all > works, and it would take me quite a while to figure out how to load > the _Unwind_Context from the sigcontext. > > Andrew. > > > >
