Re: Stack unwind across signal frame

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux