From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9990 invoked by alias); 6 Oct 2003 20:24:16 -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 9971 invoked from network); 6 Oct 2003 20:24:15 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.81.54.130) by sources.redhat.com with SMTP; 6 Oct 2003 20:24:15 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 835D7357B; Mon, 6 Oct 2003 13:24:14 -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 h96KOEN2030396; Mon, 6 Oct 2003 13:24:14 -0700 Received: (from roland@localhost) by magilla.sf.frob.com (8.12.9/8.12.9/Submit) id h96KODfk030392; Mon, 6 Oct 2003 13:24:13 -0700 Date: Mon, 06 Oct 2003 20:24:00 -0000 Message-Id: <200310062024.h96KODfk030392@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 15:42:28 -0400 <16257.50596.85774.226265@localhost.redhat.com> X-Zippy-Says: Hey, wait a minute!! I want a divorce!!.. you're not Clint Eastwood!! X-SW-Source: 2003-10/txt/msg00121.txt.bz2 > 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. > 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.) > 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. > 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. Thanks, Roland