From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6853 invoked by alias); 26 Oct 2004 08:17:49 -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 6842 invoked from network); 26 Oct 2004 08:17:47 -0000 Received: from unknown (HELO devserv.devel.redhat.com) (66.187.233.202) by sourceware.org with SMTP; 26 Oct 2004 08:17:47 -0000 Received: from devserv.devel.redhat.com (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with ESMTP id i9Q8Hins017692; Tue, 26 Oct 2004 04:17:44 -0400 Received: (from jakub@localhost) by devserv.devel.redhat.com (8.12.11/8.12.11/Submit) id i9Q8HiZg017680; Tue, 26 Oct 2004 04:17:44 -0400 Date: Tue, 26 Oct 2004 08:17:00 -0000 From: Jakub Jelinek To: Roland McGrath Cc: Daniel Jacobowitz , Mark Kettenis , gdb-patches@sources.redhat.com, ezannoni@redhat.com, cagney@gnu.org Subject: Re: [rfa] Attach vsyscall support for GNU/Linux Message-ID: <20041026081744.GF31909@devserv.devel.redhat.com> Reply-To: Jakub Jelinek References: <20041024231636.GA21927@nevyn.them.org> <200410260251.i9Q2pQbc004556@magilla.sf.frob.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200410260251.i9Q2pQbc004556@magilla.sf.frob.com> User-Agent: Mutt/1.4.1i X-SW-Source: 2004-10/txt/msg00434.txt.bz2 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. Jakub