This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [patch] allow switching stacks
- From: Daniel Jacobowitz <drow at false dot org>
- To: Jim Blandy <jimb at redhat dot com>
- Cc: Andrew Cagney <cagney at gnu dot org>, jim dot houston at comcast dot net,gdb-patches at sources dot redhat dot com
- Date: Mon, 12 Apr 2004 17:13:09 -0400
- Subject: Re: [patch] allow switching stacks
- References: <m3y8qbp650.fsf@new.localdomain> <404E2745.2090405@gnu.org> <20040409215453.GA1090@nevyn.them.org> <vt2lll07vv6.fsf@zenia.home>
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