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

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678

--- Comment #45 from Iain Sandoe <iains at gcc dot gnu.org> 2011-10-18 15:32:33 UTC ---
(In reply to comment #44)
> > 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).

that seems reasonable if the result can be cached - otherwise it's potentially
a big hit.
... or it could be done from a crt (I have in mind a new crt to try and solve
some other unwind issues).