[Bug target/50678] [4.7 Regression] FAIL: c52104y on x86_64-apple-darwin10

["ebotcazou at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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).