Ok,

I just figured out why amd64 GNU/Linux signal trampolines don't work 
correctly and the reason is scary!

After signal delivery (e.x., sigaltstack testcase) the stack looks like:

   sentinel: SENTINEL_FRAME
   catcher: NORMAL_FRAME, dwarf2 unwinder
   <sigtramp>: SIGTRAMP_FRAME, sigtramp unwinder
   thrower: NORMAL_FRAME, dwarf2 unwinder

while later after catcher has "finish"ed it looks like:

   sentinel: SENTINEL_FRAME
   __restore_rt: NORMAL_FRAME, dwarf2 unwinder
   <corrupt stack>

Notice how the first time round the trampoline was correctly identified 
but not the second.  What happened?

In the first case:

- linux jumps to catcher setting it's return address to <sigtramp>'s 
entry point
- gdb correctly identifies catcher as a callee or normal frame
- gdb goes to unwind catcher and starts sniffing <sigtramp>
- the dwarf2 sniffer, when sniffing <sigtramp>, asks for that frame's 
address-in-block, since the catcher is a normal frame, that translates 
to <catcher's-return-address>-1
- <catcher's-return-address>-1 translates into <sigtramp>-1
- since <sigtramp>-1 doesn't have any CFI (lucky eh?) dwarf2 dismisses 
the frame
- the sigtramp unwinder gets to take a wiff and identifies the frame

while in the second case (no catcher):

- the dwarf2 sniffer, when sniffing <sigtramp>, asks for that frame's 
address-in-block, since the next frame is a sentinel that translates 
into <catcher's-return-address>
- <catcher's-return-address> translates into <sigtramp>
- <sigtramp> does have CFI so dwarf2 claims the frame marking it 
"normal", outch!

So for the moment, I think the sigtramp frame should always be sniffed 
before the dwarf2 frame.  We can revisit the possability of modifing 
dwarf2 later, much later.

Andrew