From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16576 invoked by alias); 26 Oct 2004 13:27:27 -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 16372 invoked from network); 26 Oct 2004 13:27:24 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 26 Oct 2004 13:27:24 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1CMRMA-0006z2-Fm; Tue, 26 Oct 2004 09:27:22 -0400 Date: Tue, 26 Oct 2004 13:27:00 -0000 From: Daniel Jacobowitz To: Jakub Jelinek Cc: Roland McGrath , Mark Kettenis , gdb-patches@sources.redhat.com, ezannoni@redhat.com, cagney@gnu.org Subject: Re: [rfa] Attach vsyscall support for GNU/Linux Message-ID: <20041026132722.GA26490@nevyn.them.org> Mail-Followup-To: Jakub Jelinek , Roland McGrath , Mark Kettenis , gdb-patches@sources.redhat.com, ezannoni@redhat.com, cagney@gnu.org References: <20041024231636.GA21927@nevyn.them.org> <200410260251.i9Q2pQbc004556@magilla.sf.frob.com> <20041026081744.GF31909@devserv.devel.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041026081744.GF31909@devserv.devel.redhat.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-10/txt/msg00435.txt.bz2 On Tue, Oct 26, 2004 at 04:17:44AM -0400, Jakub Jelinek wrote: > On Mon, Oct 25, 2004 at 07:51:26PM -0700, Roland McGrath wrote: > > > I just don't think this problem is solvable within the existing CFI. > > > I don't know whether it is solvable by extending DWARF. Just to make > > > sure I'm on the right page, I'll recap one instance of why GDB needs to > > > know it's found a signal handler. > > > > > > Here's __kernel_rt_sigreturn (starts at 0xffffe440). > > > ffffe43f: 90 nop > > > ffffe440: b8 ad 00 00 00 mov $0xad,%eax > > > ffffe445: cd 80 int $0x80 > > > > > > Here's the unwind information: > > > 000000c4 00000044 00000084 FDE cie=00000044 pc=ffffe43f..ffffe447 > > > DW_CFA_def_cfa_expression (DW_OP_breg4: 188; DW_OP_deref) > > > DW_CFA_expression: r0 (DW_OP_breg4: 204) > > > DW_CFA_expression: r1 (DW_OP_breg4: 200) > > > DW_CFA_expression: r2 (DW_OP_breg4: 196) > > > DW_CFA_expression: r3 (DW_OP_breg4: 192) > > > DW_CFA_expression: r5 (DW_OP_breg4: 184) > > > DW_CFA_expression: r6 (DW_OP_breg4: 180) > > > DW_CFA_expression: r7 (DW_OP_breg4: 176) > > > DW_CFA_expression: r8 (DW_OP_breg4: 216) > > > DW_CFA_nop > > > > > > This is accurate. It correctly locates the saved values of all > > > registers. However, this is the frame_address_in_block problem; if the > > > first instruction of a function generates a synchronous signal, then > > > the restored value of r8 (the PC) will point to the first byte of the > > > function. GDB will use the unwind information for the previous > > > function. > > > > > > I bet you could reproduce the corresponding problem by an extremely > > > signal-heavy stress test using NPTL and asynchronous cancellation. > > > Roland, am I missing something? Won't we go off into never-never land > > > if we're at the first instruction of a function call when a signal is > > > received and we try to do a forced unwind? > > Yeah, this is a known problem, but not yet dealt with. > See http://sources.redhat.com/bugzilla/show_bug.cgi?id=300 > for details. > Option Three in Richard's #7 comment sounds the best thing to do, but > I didn't get to implement it yet. Thanks for the pointer! I've been thinking about #2; I'm not quite sure about #3. What would the expresson be used for - "evaluates non-zero" for what condition? [I've also needed something like DW_CFA_expression that didn't evaluate to a location before; if that would be useful to solve this, then we ought to add it.] -- Daniel Jacobowitz