From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7035 invoked by alias); 3 Oct 2003 23:44:09 -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 7028 invoked from network); 3 Oct 2003 23:44:08 -0000 Received: from unknown (HELO zenia.home) (12.223.225.216) by sources.redhat.com with SMTP; 3 Oct 2003 23:44:08 -0000 Received: by zenia.home (Postfix, from userid 5433) id 7035020766; Fri, 3 Oct 2003 18:43:57 -0500 (EST) To: Roland McGrath Cc: gdb-patches@sources.redhat.com Subject: Re: unwind support for Linux 2.6 vsyscall DSO References: <200310030827.h938RsrS019019@magilla.sf.frob.com> From: Jim Blandy Date: Fri, 03 Oct 2003 23:44:00 -0000 In-Reply-To: <200310030827.h938RsrS019019@magilla.sf.frob.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-10/txt/msg00068.txt.bz2 Roland McGrath writes: > Questions for the core file case: > > 1 Where should this call go in the order of operations? > > I plopped the check in the middle of core_open because it seemed like it > ought to come between the bfd opening and the register diddling that > includes some calls about the grokking of the stack frame. I don't know > how loading a symfile interacts with that diddling. Would it work to > have the symbol_file_add_from_memory done after core_open? 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. 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. 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. > 2 Where should this support go in the target/generic code split? > > This code, and the need for it, is Linux-specific but not machine-specific. > Linux 2.6 currently requires it on x86, IA64, and AMD64 (in both native and > IA32 emulation versions). The user-level support for the preloaded DSO > image is machine-independent in the glibc implementation; no other Linux > platform will overload the AT_SYSINFO_EHDR tag value for another purpose. > I would like to have this implemented in gdb in a place that doesn't > require duplication for the three existing platforms requiring the support, > and will cover any other Linux target where kernels start using the same > feature. I don't see any obvious place like a common linux-tdep.c; where > is the right place? Should it be a different to_core_open hook that wraps > the generic one? Or maybe extend struct core_fns? (But core_fns is > redefined only in machine-specific files, and it appears inconsistently > so--sometimes in *-nat.c and sometimes in *-tdep.c; what's the story?) It seems to me this belongs in a new linux-tdep.c file. Regarding the code: 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.