Re: Help: Unwinding the C++ stack...throw, longjmp & threads

[Jamie Lokier <jamie.lokier@cern.ch>]

Jason Merrill wrote:
> >>>>> Jamie Lokier <jamie.lokier@cern.ch> writes:
> 
>  > I would think improving the .eh_frame info so that functions without 
>  > unwind handlers don't take any space in .eh_frame.  I.e., some mechanism
>  > for "default unwinding" using the frame pointer.
> 
> .eh_frame has nothing to do with how many handlers a function has; it tells
> the unwinder how to reload the registers saved in the function prologue so
> that they have the right values when we get to a handler in the caller.
> 
> It is possible to do unwinding without .eh_frame; gdb does it by
> disassembling the prologue, but this doesn't always work.  
> 
> Another possiblity would be to declare that all registers are clobbered on
> entry to an exception handler; then the default unwinder would only have to
> worry about how to find the return address and saved stack pointer for a
> frame, which is usually straightforward if you have a frame pointer to work
> with.

Possibility #2: do the disassembly thing as GDB does, but emit .eh_frame
info and unwinding code for functions where that would not work.
Complicated to implement.

Possibility #3: store a compact, special entry in .eh_frame per function
that means "unwind using frame pointer, and restore regs from base of
stack where REGMASK has bits set for regs to restore".  As usual, normal
.eh_frame+unwinder for cases where this fails, if any.

Possibility #4: the epilogue for a function normally balances the
prologue.  A 12 byte entry in .eh_frame (or smaller if compressed) that
contains the start address of the function, the address of the epilogue,
and the stack offset relative to the frame pointer, should work in most
cases.  12 bytes in .eh_frame for each function that clobbers any
callee-saved registers is not much overall.

-- Jamie