Re: [patch] allow switching stacks

[Daniel Jacobowitz <drow@false.org>]

On Mon, Apr 12, 2004 at 04:02:37PM -0500, Jim Blandy wrote:
> 
> Daniel Jacobowitz <drow@false.org> writes:
> > There's no way in unwind information to annotate a non-call frame,
> > which is the common relevant property for signal frames, dummy frames,
> > and interrupt handler frames.   Should there be?
> 
> There isn't?  For signal frames, for example, the registers are all
> saved in the ucontext_t, on the signal handler's stack.  Can't we
> hand-build Dwarf 2 CFI that points into the ucontext_t?
> 
> On IA-32 machines, the processor saves %eflags, %eip, and %cs, and
> possibly %esp and %ss, and it's up to the handler code to save
> whatever else needs preserving.  We could hand-build Dwarf 2 CFI for
> that, too.

That's not what I meant.  In fact, if my memory serves me right, the
vsyscall DSO support that Roland is still submitting may let us see
CFI for the signal trampoline, courtesy of the kernel.

But there's no flag in the CFI that says 'this is a non-call frame'. 
So anything that assumes it is dealing with call frames will break if
we let the dwarf2 unwinder take precedence over the sigframe unwinder:
  - we won't get <signal frame> messages, which is mostly cosmetic,
    but not entirely - think unwindonsignal
  - frame_address_in_block will try to subtract from the saved PC
  - the inner-than check in this thread will be confused
  - et cetera.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer