linux-mips
[Top] [All Lists]

Stack unwind across signal frame

To: linux-mips@linux-mips.org, linux-kernel@vger.kernel.org
Subject: Stack unwind across signal frame
From: Alan Cooper <alcooperx@gmail.com>
Date: Fri, 17 Feb 2012 16:13:54 -0500
Authentication-results: mr.google.com; spf=pass (google.com: domain of alcooperx@gmail.com designates 10.52.29.241 as permitted sender) smtp.mail=alcooperx@gmail.com; dkim=pass header.i=alcooperx@gmail.com
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=LppqU253m/LCE42418D3LZxx/9PAq2ucoAFMMsp94FY=; b=YgycvGy01Gwe5cjj2q0V8L2ZiYMO4r4VDGzZL6I0enewXyFwKnb5pfZtqPshsPTmWP MVVQjkysofpy7CN5YpOtkhs5FVYLewY1cg9QSYAq/uMHgaNJMn2SQraxI6feuQJQ9gA2 RaFYMZJQlf3lIG+MIWdrBhAuUIyPEIeiVhiyg=
Sender: linux-mips-bounce@linux-mips.org
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. It looks like this is caused by
the VDSO code that was added 2/2010. 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.

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?

If this is correct, then it seems like the best solution would be to
add the VDSO eh_frame info to MIPS.

Thanks
Al Cooper

<Prev in Thread] Current Thread [Next in Thread>