From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2435 invoked by alias); 7 Oct 2003 00:17:56 -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 2428 invoked from network); 7 Oct 2003 00:17:56 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 7 Oct 2003 00:17:56 -0000 Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian)) id 1A6fY3-0004NL-Rr for ; Mon, 06 Oct 2003 20:17:55 -0400 Date: Tue, 07 Oct 2003 00:17:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: unwind support for Linux 2.6 vsyscall DSO Message-ID: <20031007001755.GB16602@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <16257.58804.651249.85543@localhost.redhat.com> <200310062359.h96Nxqgt032566@magilla.sf.frob.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200310062359.h96Nxqgt032566@magilla.sf.frob.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-10/txt/msg00143.txt.bz2 On Mon, Oct 06, 2003 at 04:59:52PM -0700, Roland McGrath wrote: > > There should be an iterator over the entries in the /proc/pid/auxv > > file with a callback that processes each entry. So that the iterator > > could be used not just for finding the AT_SYSINFO_EHDR entry. > > Ok, an iterator interface is fine with me, just marginally less efficient > than the searcher when only one tag is actually used (and more efficient if > many tags are used). (I had not proposed any function that would be useful > solely for AT_SYSINFO_EHDR, though that was one of Jim's early > suggestions.) If others agree this is the right interface for a target_ops > addition, I will write that patch. > > > I think the number of iterations would be your size_t above divided by > > the size of an auxv_t or something similar. > > Indeed. > > > The first thing that happens is that the breakpoint inserted at the > > dynamic linker is hit, at which point gdb gets to add the shlibs. > > Obviously that's not the first thing, since inserting the breakpoint in the > dynamic linker happens before that. It's ideal to do the vsyscall DSO > setup before letting the dynamic linker run at all. That way you have that > information in case you get a signal in the early part of dynamic linker > startup, or attach to a process that is for some reason blocked in a system > call in that early stage, and want to see a backtrace to understand the > state. I agree that this would be nice. This'll require a new hook. Preferably it should be done using the new observers mechanism. > > enable_break: search for .interp in /scratch/ezannoni/pie-work/native/gdb/testsuite/gdb.base/break > > enable_break: opening /lib/ld-linux.so.2 > > elf_locate_base: DT_DEBUG entry has value 0x0 > > svr4_current_sos: no DT_DEBUG found > > I don't see your debugging code in mainline gdb and so I can only guess > what these messages mean in terms of the code. > > Are you sure this doesn't mean it looked at the sh process before it > exec'd? It wouldn't find anything there because it would be looking for > DT_DEBUG from the .dynamic address of the "break" binary and sh's layout is > different (so it's reading arbitrary other data and not finding the tag). > > > Since we need the iterator method, this read/parse becomes a very > > small piece and fits nicely in linux-proc.c in the live inferior > > case. For the corefile/remote case, you would ask bfd for the .auxv > > section of the core file and parse that in order to get an element of > > the vector and this is also something that can be in gdb, unless you > > want to reuse that in some other tool. > > We are all clear on the steps that need to be performed. The part that > parses the format and deals with the target wordsize question and > byteswapping, is common work between the live and core cases that might use > a shared function rather than duplicative source code. That is what we > have been discussing. > > You said "corefile/remote case", but looking for a .auxv section applies > only to core files. I don't think we have discussed the remote case. It > would require the remote stub reading the local /proc/PID/auxv file and > giving the information back to gdb. I'm not aware of anything in the > remote protocol to allow that. No, but extending it to do so is easy (and vital). I'll do it later. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer