From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22959 invoked by alias); 6 Oct 2003 21:48:33 -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 22918 invoked from network); 6 Oct 2003 21:48:32 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 6 Oct 2003 21:48:32 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h96LmV122965 for ; Mon, 6 Oct 2003 17:48:31 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h96LmVc06717 for ; Mon, 6 Oct 2003 17:48:31 -0400 Received: from localhost.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id h96LmUbe023861; Mon, 6 Oct 2003 17:48:30 -0400 Received: by localhost.redhat.com (Postfix, from userid 469) id 658532CC88; Mon, 6 Oct 2003 17:59:17 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16257.58804.651249.85543@localhost.redhat.com> Date: Mon, 06 Oct 2003 21:48:00 -0000 To: Roland McGrath Cc: Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: unwind support for Linux 2.6 vsyscall DSO In-Reply-To: <200310062024.h96KODfk030392@magilla.sf.frob.com> References: <16257.50596.85774.226265@localhost.redhat.com> <200310062024.h96KODfk030392@magilla.sf.frob.com> X-SW-Source: 2003-10/txt/msg00131.txt.bz2 Roland McGrath writes: > > Ok, reading the thread, I see that you are running pretty much into > > the same problems I am running into for PIE support. What kind of > > information is exacty exported into the auxv file? I am wondering if > > you also have the entry point of the program there (AT_ENTRY, looking > > at the Solaris auxv.h), because if so it may change my current way of > > looking at PIE, where I am taking the info from the /proc/pid/map > > file, which is not saved in the core file, I think, while auxv is. > > Try "LD_SHOW_AUXV=1 /bin/true" (i.e. put that in the environment of any > program--it's checked by the dynamic linker). That shows you all the > information that the kernel supplies in this fashion (you have to be using > Linux 2.6 to see AT_SYSINFO and AT_SYSINFO_EHDR in there). AT_ENTRY is > certainly there--that's how the dynamic linker knows where to jump to start > the program after initialization. There is also AT_PHDR, which is another > thing that gives you the runtime address of something that you know the > link-time address of (PT_PHDR). If access to AT_ENTRY alone doesn't solve > your problem with PIE, I'd like to help figure out what else it is you > need; so please raise that in a separate thread CC'd to me. > ok. > > Anyway, this issue aside, there is a target method in gdb to process the > > various entries in the map file. I think it would be appropriate to > > translate that into something similar for reading the auxv file. > > Ok. This is what Jim suggested too. Do you have a function signature in mind? > Perhaps: > > int (*to_get_auxv_data) (char **data, size_t *size); > > that fills in a malloc'd block. (The data will be examined briefly and > thrown away, but malloc seems like the simplest clean interface to use.) > 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. I think the number of iterations would be your size_t above divided by the size of an auxv_t or something similar. For instance something like the one for solaris: * Call a callback function once for each mapping, passing it the mapping, * an optional secondary callback function, and some optional opaque data. * Quit and return the first non-zero value returned from the callback. * * Arguments: * pi -- procinfo struct for the process to be mapped. * func -- callback function to be called by this iterator. * data -- optional opaque data to be passed to the callback function. * child_func -- optional secondary function pointer to be passed * to the child function. * * Return: First non-zero return value from the callback function, * or zero. int iterate_over_mappings (procinfo *pi, int (*child_func) (), void *data, int (*func) (struct prmap *map, int (*child_func) (), void *data)) In this case, instead of a prmap structure we would have an auxv_t structure, or something like that. Doesn't need to be that complicated as the one above. The linux one for reading MAP is a bit simpler. > > I agree that treating this new information as much as possible as a > > shared library will make our life easier, because all the checks are > > done in the right spots already. > > and Jim wrote: > > > I think you can rely on SOLIB_ADD not being called too early. It would > > be a bug if we ever called it before the shell execs the executable under > > debug, because we use the VMA of the .dynamic section of the executable > > file to find the dynamic structure in the inferior's memory anyway. We > > couldn't even find the shell's shared library list. > > Right, it would fail to find any list at all. If it treats that as "empty > list" then this won't be a change from before and so it's a harmless no-op. > Are we sure that is not what is happening now? If it is, it's harmless now > but having the auxv-reading done too early would not be harmless. > 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. For instance with the debug output enabled: [...start up gdb...] (gdb) set debug solib 1 (gdb) b main Breakpoint 1 at 0x80484ce: file /scratch/ezannoni/pie-work/src/gdb/testsuite/gdb.base/break.c, line 75. (gdb) r Starting program: /scratch/ezannoni/pie-work/native/gdb/testsuite/gdb.base/break 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 enable_break: solib bp set <<<<<<<>>>>>>> elf_locate_base: DT_DEBUG entry has value 0x400136bc svr4_current_sos: Processing DSO: /lib/i686/libm.so.6 svr4_current_sos: Processing DSO: /lib/i686/libc.so.6 svr4_current_sos: Processing DSO: /lib/ld-linux.so.2 svr4_current_sos: Processing DSO: /lib/i686/libm.so.6 svr4_current_sos: Processing DSO: /lib/i686/libc.so.6 svr4_current_sos: Processing DSO: /lib/ld-linux.so.2 svr4_current_sos: Processing DSO: /lib/i686/libm.so.6 svr4_current_sos: Processing DSO: /lib/i686/libc.so.6 svr4_current_sos: Processing DSO: /lib/ld-linux.so.2 I think we are safe here. > > I disagree with moving the read of auxv to bfd. Gdb already processes > > plenty of /proc files (on Solaris using 2 interfaces), and has target > > methods defined for these, so I would treat the auxv case just like the > > others. > > What we have been discussing most recently is only a BFD utility function > to examine raw auxv blocks that have already been read in somehow. > i.e., a trivial helper function that these target methods would use. > It doesn't matter to me whether this is in bfd/elf.c or gdb/elfread.c. > > 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. elena > > Thanks, > Roland