From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32643 invoked by alias); 26 Oct 2004 02:51:31 -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 32629 invoked from network); 26 Oct 2004 02:51:30 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.81.54.130) by sourceware.org with SMTP; 26 Oct 2004 02:51:30 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id F0A31357B; Mon, 25 Oct 2004 19:51:28 -0700 (PDT) Received: from magilla.sf.frob.com (localhost.localdomain [127.0.0.1]) by magilla.sf.frob.com (8.12.11/8.12.9) with ESMTP id i9Q2pR3v004560; Mon, 25 Oct 2004 19:51:27 -0700 Received: (from roland@localhost) by magilla.sf.frob.com (8.12.11/8.12.11/Submit) id i9Q2pQbc004556; Mon, 25 Oct 2004 19:51:26 -0700 Date: Tue, 26 Oct 2004 02:51:00 -0000 Message-Id: <200410260251.i9Q2pQbc004556@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Daniel Jacobowitz Cc: Jakub Jelinek Cc: Mark Kettenis , gdb-patches@sources.redhat.com, ezannoni@redhat.com, cagney@gnu.org Subject: Re: [rfa] Attach vsyscall support for GNU/Linux In-Reply-To: Daniel Jacobowitz's message of Sunday, 24 October 2004 19:16:36 -0400 <20041024231636.GA21927@nevyn.them.org> X-Windows: graphics hacking :: Roman numerals : sqrt (pi) X-SW-Source: 2004-10/txt/msg00428.txt.bz2 I'm punting this to Jakub as the person more knowledgeable about how the unwind info is used for exception handling in glibc. > 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?