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