From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5798 invoked by alias); 12 Apr 2004 21:13:18 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 5776 invoked from network); 12 Apr 2004 21:13:12 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 12 Apr 2004 21:13:12 -0000 Received: from drow by nevyn.them.org with local (Exim 4.31 #1 (Debian)) id 1BD8jt-0000Vx-3x; Mon, 12 Apr 2004 17:13:09 -0400 Date: Mon, 12 Apr 2004 21:13:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: Andrew Cagney , jim.houston@comcast.net, gdb-patches@sources.redhat.com Subject: Re: [patch] allow switching stacks Message-ID: <20040412211309.GA1900@nevyn.them.org> Mail-Followup-To: Jim Blandy , Andrew Cagney , jim.houston@comcast.net, gdb-patches@sources.redhat.com References: <404E2745.2090405@gnu.org> <20040409215453.GA1090@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-04/txt/msg00263.txt.bz2 On Mon, Apr 12, 2004 at 04:02:37PM -0500, Jim Blandy wrote: > > Daniel Jacobowitz 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 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