From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23069 invoked by alias); 13 May 2003 01:53:20 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 22839 invoked from network); 13 May 2003 01:53:18 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.163.213.212) by sources.redhat.com with SMTP; 13 May 2003 01:53:18 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 3639D354C; Mon, 12 May 2003 18:53:17 -0700 (PDT) Received: (from roland@localhost) by magilla.sf.frob.com (8.11.6/8.11.6) id h4D1rGW23237; Mon, 12 May 2003 18:53:16 -0700 Date: Tue, 13 May 2003 01:53:00 -0000 Message-Id: <200305130153.h4D1rGW23237@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Mark Kettenis Cc: gdb@sources.redhat.com Subject: Re: gdb support for Linux vsyscall DSO In-Reply-To: Mark Kettenis's message of Monday, 12 May 2003 01:14:21 +0200 <200305112314.h4BNELkE002799@elgar.kettenis.dyndns.org> X-Windows: foiled again. X-SW-Source: 2003-05/txt/msg00215.txt.bz2 > There is some special handling for signal trampolines in > infrun.c:handle_inferior_event(). Beware! Dragons can still be found > in that function. However, it seems the bit of code I'm talking about > is there for targets that don't known how to properly unwind signal > frames :-). I only partly follow the code in that function, but it does look like it wants to know whether it's in a signal frame. I get the impression that "next" or "step" interrupted by a signal lets the signal be handled and continues until the end of the source line rather than doing a normal user stop for the signal, and that this is considered desireable. So it must know. Having a DWARF2 extension to mark signal frames seems reasonable, and less kludgey than matching symbol names. However, I wonder if there is in fact a way to do it that won't confuse older libgcc's .eh_frame unwinding code. > Restoring %eflags is certainly possible. Making GDB actually pop the > signal trampoline frame should work I only mentioned %eflags to pedantic because I caught myself about to say "restore the exact state of the interrupted thread" and that wasn't completely true. I don't anticipate gdb having any reason to want to roll back a signal frame. (However, in the abstract it seems like the right thing for the kernel unwind info to describe restoring %eflags if the DWARF2 format can already represent that.) > Well, for processes started by GDB we can read the auxiliary vector from > the pristine stack, but that doesn't work for attached-to processes. Good point. I am inclined to think this is worth doing because, for the case it covers, it is both fully robust and fully remote-friendly even with old existing remote stubs, and is easy enough to implement on a per-target basis. If a direct inquiry is available, that will still be quicker than the straightforward but numerous inferior memory reads that must be done to extract the information from the stack, and so is the first choice; if it's available for remote too, all the better. But I think I will implement this fallback at least for i386, just because it's a 100% correct solution for at least half the cases (i.e. run but not attach) that can work today without waiting for the a new kernel feature and/or remote stub upgrades to be installed. > Given that we know where the dynamic section is from l_ld, I think we > can figure out all we need to know from there. As a special case for the Linux vsyscall DSO, it would be adequate just to presume it will fit in a single page and round down. But you've reminded me that there are other useful addresses to be found by looking in the .dynamic section itself. DT_HASH gives the location of the .hash section, which a normal ld -shared always puts as the first section in the file, appearing right after the file and program headers. Without relying on .hash being first per se, you can reasonably assume that the sections referenced by DT_* are the first group in the file and so start with the lowest of those addresses. Rounding that address down to the smallest of any actual ELF platform's page size (which might be 4k?) is a pretty darn reasonable guess for finding the ELF header of any mapped DSO. Thanks much for all the helpful feedback, Roland