From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27932 invoked by alias); 13 May 2003 02:29:58 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 27553 invoked from network); 13 May 2003 02:29:53 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.163.213.212) by sources.redhat.com with SMTP; 13 May 2003 02:29:53 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 5376A354C; Mon, 12 May 2003 19:29:52 -0700 (PDT) Received: (from roland@localhost) by magilla.sf.frob.com (8.11.6/8.11.6) id h4D2Tp723361; Mon, 12 May 2003 19:29:51 -0700 Date: Tue, 13 May 2003 02:29:00 -0000 Message-Id: <200305130229.h4D2Tp723361@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Andrew Cagney Cc: Daniel Jacobowitz , gdb@sources.redhat.com Subject: Re: gdb support for Linux vsyscall DSO In-Reply-To: Andrew Cagney's message of Monday, 12 May 2003 15:17:06 -0400 <3EBFF332.7040108@redhat.com> X-Zippy-Says: What's the MATTER Sid?.. Is your BEVERAGE unsatisfactory? X-SW-Source: 2003-05/txt/msg00216.txt.bz2 > To follow up my own e-mail. On Solaris, there is: > > /proc/PID/auxv [...] > So the /proc solution even as ``prior art''. Indeed. When I said, "like /proc/PID/auxv on Solaris", I was in fact citing the existing Solaris interface as exactly what we might do. However, as I said and for reasons I explained, we might not get buy-in from kernel maintainers for supporting that. I don't think that the prior art of Solaris interfaces is something they find particularly compelling. I'm not saying this feature won't happen--I certainly like it fine. My intent in starting the thread about the various possible sorts of kernel interface was to flesh out the full range of acceptable options and their preference ordering from the gdb perspective, to have on hand when I go and argue for whichever of them we can get from the kernel maintainers. > and the corresponding core file includes a .note section that contains I'm aware of the Solaris formats (which are all pretty reasonable). If Linux kernel maintainers accept the /proc/PID/auxv implementation, then I am quite sure they will also accept NT_AUXV note writing (the kernel support required is the same for both). However, the core note does not provide any new magic bullet. There would still be new code required to grok it; that code is straightforward, but both a bit more complex and a bit more costly than the core phdr support that is already there now. > As for the remote case, I think GDB's remote protocol (via the target > vector) should allow access to the remote file system (lib*.so, /proc, > ....) anyway. Doing that would let the OS dependant code access the > remote /proc/PID/aux. All sorts of useful things would suddenly ``just > work''. I have nothing against that. It obviously makes any /proc-based solution work for remote (requiring /proc be mounted is an issue for both native and remote). I assume then that linux-proc.c would be made to use some new target interface for the file-reading and thus start working via remote. Then the support for reading either /proc/PID/auxv or /proc/PID/maps to discern the vsyscall DSO address naturally fits there, machine-independent. > To me this looks like the simplest and cleanest way of solving the > problem. A conistent mechanism to find the address, and a single > technique for accessing the .eh_frame info. That has to be better than > approaches that require per-target custom modifications for what is a > Linux specific problem. As I said before, I am certainly happiest with someplace to put the kernel-specific support that is not machine-specific. The support for using core file phdrs (to sort of treat the core file as if it were the DSO) is so simple (and already works), that I am inclined to leave that rather than reading the vsyscall DSO image out of the core file memory dump after using the NT_AUXV note to locate it. The code for making a bfd from the in-memory DSO image is already needed for the live case, so that's not extra work. But as well as it being more efficient to use the core file bfd directly rather than read part of the file into memory and make that into a separate bfd, it's also simpler, slightly more efficient, and already done(!), to use the core file's PT_GNU_EH_FRAME (and then you've got it right there) than to even to look for an NT_AUXV note and the AT_SYSINFO_EHDR element within it before you can fake up the bfd and search it for eh_frame. Thanks, Roland