From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2325 invoked by alias); 12 May 2003 19:23:34 -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 6084 invoked from network); 12 May 2003 19:17:14 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.131) by sources.redhat.com with SMTP; 12 May 2003 19:17:14 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id C06722B2F; Mon, 12 May 2003 15:17:06 -0400 (EDT) Message-ID: <3EBFF332.7040108@redhat.com> Date: Mon, 12 May 2003 19:23:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roland McGrath , Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: gdb support for Linux vsyscall DSO References: <200305101942.h4AJgoe32699@magilla.sf.frob.com> <3EBD73CA.10807@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg00203.txt.bz2 > Any way, re-reading your post yes, the info is in there. If the address is known, GDB can pull the contents out of memory. Given the list of targets: > > - core > - native attach > - native run > - remote > - ?more? > > I believe the choices are: > > - find a way of determing that address across all of these targets :-/ > - implement per-target custom mechanisms for pulling out this information (creating a need to test/implement each target separatly - vis the corefile + dwarf2 changes) :-// > > So, it possible to find the address (symbol?, /proc, shlib load table, ...?) for all targets? > > /proc/PID/map, on a remote, is a possability. A remote version of find_memory_regions() would be useful anyway - clean up gcore a bit. However, the down side is that a system with no /proc mounted wouldn't debug very well :-/ To follow up my own e-mail. On Solaris, there is: /proc/PID/auxv and the corresponding core file includes a .note section that contains (man core.4): auxv_t array n_type: NT_AUXV. This entry contains the array of auxv_t structures that was passed by the operating system as startup information to the dynamic linker. Auxiliary vector information is defined in . So the /proc solution even as ``prior art''. 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''. 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. Andrew