Messages in this thread | | | Date | Sat, 18 Feb 2012 09:05:52 -0800 | From | David Daney <> | Subject | Re: Stack unwind across signal frame |
| |
On 02/17/2012 01:13 PM, Alan Cooper wrote: > I'm seeing a problem on both 2.6.37 and 3.3 MIPS kernels where I can't > unwind through a MIPS signal frame. You don't tell us the version of the unwinder (likely from libgcc) you are using. There was a lot of work in this area four or five years ago, I didn't take the time to do the required archaeology to determine the exact patch, but likely you are missing this.
> It looks like this is caused by > the VDSO code that was added 2/2010. Some CPUs have errata necessitating a different signal frame layout, on these CPUs, you wouldn't be able to unwind either, even pre mips-vdso.
> When the unwinder tries to find > the frame info for the caller of the signal handler (the trampoline in > VDSO), it can't find the eh_frame info because the address is in the > VDSO area and stops unwinding. It looks like other platforms solve > this by adding the eh_frame info for the VDSO area so the lookup > works.
That's right. However all 'modern' GCCs and GDBs can unwind through signal frames on all 2.4.x and later kernels. I would recommend upgrading your GCC to 4.6.2, and see if you obtain better results.
> This problem ends up breaking pthread cleanup for C++ programs because > the cleanup is done using a class with the expectation that the > destructor will be called when the thread gets canceled by a cancel > signal. This seems like a big problem for all current MIPS kernels so > I was wondering if I'm missing something?
A modern libgcc I think.
> > If this is correct, then it seems like the best solution would be to > add the VDSO eh_frame info to MIPS.
Having a correct eh_frame in the vdso, would be nice, but is not the highest priority for me.
David Daney
| |