From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18201 invoked by alias); 4 Oct 2003 00:10:46 -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 18193 invoked from network); 4 Oct 2003 00:10:45 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.81.54.130) by sources.redhat.com with SMTP; 4 Oct 2003 00:10:45 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 98E90357B; Fri, 3 Oct 2003 17:10:44 -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 h940AhN2021285; Fri, 3 Oct 2003 17:10:43 -0700 Received: (from roland@localhost) by magilla.sf.frob.com (8.12.9/8.12.9/Submit) id h940AhG5021281; Fri, 3 Oct 2003 17:10:43 -0700 Date: Sat, 04 Oct 2003 00:10:00 -0000 Message-Id: <200310040010.h940AhG5021281@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Jim Blandy Cc: gdb-patches@sources.redhat.com Subject: Re: unwind support for Linux 2.6 vsyscall DSO In-Reply-To: Jim Blandy's message of , 3 October 2003 18:43:56 -0500 X-Shopping-List: (1) Rustic argumentation cancer (2) Complaisant losers (3) Cubical dandelion logs (4) Drastic loquacious auditions X-SW-Source: 2003-10/txt/msg00069.txt.bz2 > It seems to me that it should be handled as much like other shared > libraries as possible. So at the point where we load symbols for the > shared libraries that a core file references, we also want to load the > vsyscall library, if it exists. Same for attach and run. I certainly agree with this in principle. But in practice I found that other shared libraries are handled with complicated hair that it's difficult to figure out exactly who calls and when, so I got scared. > One approach might be for Linux to define its own linux-solib.h, which > #defines SOLIB_ADD and SOLIB_CLEAR to call linux-tdep.c functions that > do the standard dynamic linker stuff, but then check the auxv for an > AT_SYSINFO_EHDR entry and handle that, too. That would make things > work pretty consistently for the core, attach, and run cases. What can I see SOLIB_ADD gets called a lot, and every time it reconstructs the inferior's list of objects and compares to gdb's list to see if there are any new ones. The vsyscall DSO is always there and is only possibly changed by an exec, so it doesn't make sense to re-check its location a lot. Should this SOLIB_ADD then just store whether it has checked yet and clear that record in SOLIB_CLEAR? > It seems to me that there should be a target vector method for > accessing the auxv information, since there's one native-specific way > to do it for attach and run, and a core-specific way to do it for core > files. But it's Linux-specific information. Well, actually, any OS > that uses the SYSV-style program invocation process is going to work > that way, so maybe it's justifiable. I don't know. The notion of auxv information is at least ELF-specific, and in fact a little more specific than that (a system need not use the canonical program startup stack protocol to use the ELF file formats). The style of getting the auxv information is so far the same on every system I'm aware of that provides a method, i.e. Solaris and Linux (now) both have NT_AUXV in core files and /proc/PID/auxv for live processes. > It seems to me this belongs in a new linux-tdep.c file. Agreed. > Would it be appropriate to move auxv_parse into BFD? If I remember > right, the dynamic linker parses the auxilliary vector into an array > indexed by AT_* values; GDB could call something like that, and then > just pick out the AT_SYSINFO_EHDR value pretty easily. Though the AT_* values in use are a small set with few holes, it's actually an arbitrary tag and not an index of any kind. Nothing general-purpose can assume the range of values is appropriate for an index, and no API should. BFD is overkill for this (not that I'm saying BFD isn't overkill for everything). There is no variation in the format among ELF flavors, it's just an even number of words in the format word size. The very notion of an auxilliary vector is ELF-specific; if a non-ELF backend had something useful to export in the way of an auxilliary data from somewhere extraction interface, it seems doubtful it would be a useful abstraction to call the two the same thing in the frontend interface. I don't have any objection to moving the parsing portion out somewhere else, but making it any more overblown than the few dozen lines of code it is would be pointless IMHO.