http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678
--- Comment #44 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-10-18 15:22:14 UTC --- > Created attachment 25540 [details] > demonstration of the fault using c++/vendor's tools > > after Eric solved my inverted-logic thinko ... > .. I reproduced using g++-4.2 > bug filed as radar #10302855. Thanks! > I think we'll need to apply the patch in the short/medium term and then figure > out how to control it - which will depend on which system(s) a fix is released > for. One approach could be to scan the unwind info of _sigtramp live and check for the problematic pattern. You call __builtin_return_address from the handler to get the PC of _sigtramp, then _Unwind_Find_FDE on this PC and you scan starting from the address you get (the length of the FDE of _sigtramp is 0xc0 currently). The problematic pattern are the lines: 0x7fff85ccff61: 0x10 0x01 0x05 0x73 0x30 0x06 0x23 0x18 and 0x7fff85ccff71: 0x10 0x03 0x05 0x73 0x30 0x06 0x23 0x28 The register number is the second field (1 or 3) and the offset in the context is the 8th and last field (0x18 or 0x28). The problem is here if they are in the same relative order (the likely fix will be to swap 0x18 and 0x28 in the unwind info).
