From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31539 invoked by alias); 18 Jul 2006 18:39:16 -0000 Received: (qmail 31524 invoked by uid 22791); 18 Jul 2006 18:39:15 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Tue, 18 Jul 2006 18:39:12 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1G2uTO-0006H4-FL; Tue, 18 Jul 2006 14:39:10 -0400 Date: Tue, 18 Jul 2006 18:50:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: gdb@sourceware.org, libc-alpha@sourceware.org Subject: Re: Notes on a frame_unwind_address_in_block problem Message-ID: <20060718183910.GB17864@nevyn.them.org> Mail-Followup-To: Mark Kettenis , gdb@sourceware.org, libc-alpha@sourceware.org References: <20060706222157.GA1377@nevyn.them.org> <200607132020.k6DKKCSB023812@elgar.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200607132020.k6DKKCSB023812@elgar.sibelius.xs4all.nl> User-Agent: Mutt/1.5.11+cvs20060403 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-07/txt/msg00133.txt.bz2 On Thu, Jul 13, 2006 at 10:20:12PM +0200, Mark Kettenis wrote: > > Date: Thu, 6 Jul 2006 18:21:57 -0400 > > From: Daniel Jacobowitz > > II. 32-bit. > > > > For 32-bit, though, it gets even more interesting. Here's where $SUBJECT > > comes into play. I have a loaded vDSO (virtual shared object), which > > exports __kernel_sigreturn. This points at the first instruction of the > > trampoline, i.e. one byte after the start of the dwarf2 FDE. When I am > > stopped in the signal handler, frame_unwind_address_in_block decides to > > subtract one. That points before the symbol, so the frame ID's function > > ends up being NULL; there's no symbol covering that address. Then when we > > arrive at the signal trampoline during "finish", we no longer subtract one > > - since we're at an executable instruction in the topmost frame - and thus > > we do find the symbol. The two frame IDs don't compare equal. > > Ouch. So in the end having the signal trampoline call the signal > handler *is* a better design. Um, I guess it depends what your goal is. Given the rest of the system architecture, for GNU/Linux, that'd waste a call instruction and some code space; not much difference really. > > Another solution would be to use the FDE start address as the code address > > for dwarf2 signal frame IDs, instead of the function. This would work on > > the assumption that a single FDE would generally cover the entire trampoline > > - a reasonable assumption, I think, and the consequences for the frame ID > > changing while single-stepping are less disruptive here than the > > alternative. > > > > Mark, what do you think of that idea? It seems to work. It looks like the > > patch at the end of this message. > > In general, I think it's a bad idea to do this, but for the special > case of a signal frame, especially in the presence of the 'S" > augmentation, that might be a reasonable thing to do. However, I > think we can do better than that. What about checking whether the > address returned by frame_unwind_address_in_block() is equal to the > FDE start address and add one bytes if that's the case before looking > up the function corresponding to that address? Unfortunately we can't readily; we'd have to add a bit of new code, since all that's there is a call to frame_func_unwind (next_frame) and that has no way to do the right thing. I'd like to trigger off the signal augmentation. If you'd prefer to check the FDE start address, could you show me exactly what you have in mind? With that patch plus the fixed unwind information gdb.base/*.exp results are basically clean for x86_64 - best I've ever seen them. There is a corefile issue which I think is kernel related, and two annotation tests fail because they don't account for a glibc with debug information enabled. -- Daniel Jacobowitz CodeSourcery