From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27190 invoked by alias); 6 Oct 2003 23:59:55 -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 27182 invoked from network); 6 Oct 2003 23:59:54 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.81.54.130) by sources.redhat.com with SMTP; 6 Oct 2003 23:59:54 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 5CFB5357B; Mon, 6 Oct 2003 16:59:53 -0700 (PDT) Received: from magilla.sf.frob.com (localhost.localdomain [127.0.0.1]) by magilla.sf.frob.com (8.12.9/8.12.9) with ESMTP id h96NxrN2032570; Mon, 6 Oct 2003 16:59:53 -0700 Received: (from roland@localhost) by magilla.sf.frob.com (8.12.9/8.12.9/Submit) id h96Nxqgt032566; Mon, 6 Oct 2003 16:59:52 -0700 Date: Mon, 06 Oct 2003 23:59:00 -0000 Message-Id: <200310062359.h96Nxqgt032566@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Elena Zannoni Cc: gdb-patches@sources.redhat.com Subject: Re: unwind support for Linux 2.6 vsyscall DSO In-Reply-To: Elena Zannoni's message of Monday, 6 October 2003 17:59:16 -0400 <16257.58804.651249.85543@localhost.redhat.com> X-Shopping-List: (1) Inconstant winds (2) Bicentennial abolitionists (3) Jellied L'eggs money X-SW-Source: 2003-10/txt/msg00140.txt.bz2 > 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. > 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. Thanks, Roland