From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23885 invoked by alias); 7 Oct 2003 03:53:23 -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 23878 invoked from network); 7 Oct 2003 03:53:22 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 7 Oct 2003 03:53:22 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id DEAA42B89; Mon, 6 Oct 2003 23:53:20 -0400 (EDT) Message-ID: <3F8238B0.50409@redhat.com> Date: Tue, 07 Oct 2003 03:53:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roland McGrath , Elena Zannoni Cc: gdb-patches@sources.redhat.com Subject: Re: unwind support for Linux 2.6 vsyscall DSO References: <200310070013.h970Ddai032605@magilla.sf.frob.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg00158.txt.bz2 >> > There should be an iterator over the entries in the /proc/pid/auxv >> > file with a callback that processes each entry. So that the iterator >> > could be used not just for finding the AT_SYSINFO_EHDR entry. > >> >> Ok, an iterator interface is fine with me, just marginally less efficient >> than the searcher when only one tag is actually used (and more efficient if >> many tags are used). (I had not proposed any function that would be useful >> solely for AT_SYSINFO_EHDR, though that was one of Jim's early >> suggestions.) If others agree this is the right interface for a target_ops >> addition, I will write that patch. > > > Actually, I think this is not as useful an interface as one that fetches > the whole block for you. There is another use for this call besides the > Linux-specific AT_SYSINFO_EHDR check: gcore. We want gcore to produce > NT_AUXV notes in core dumps so that those core dumps can be used to extract > whatever AT_* information we could extract from core dumps written by a kernel. > > This is easy to add either way, but is cleaner, simpler, and more efficient > if it just writes the whole block uninterpreted than if it dissects and > reassembles it. For this to work, there will need to be mechanisms that: - unpack an architecture's auxv - pack an architecture's auxv - transport the auxv from the target, to GDB. The problem then is how to arrange these mechanisms so that they integrate well enough to work both native and cross (i386 on amd64 is considered a cross), be consistent with other gdb mechanisms and direction: target vector xfers via an iterator: - the low native code would be using the unpack method - the PIE and VSYSCALL code would be very simple - the CORE file code would need the pack method - the low remote could on-demand read the data target vector xfers raw data: - the low native code would be simple - the PIE and VSYSCALL code would need to use the unpack method - the CORE file code would just write out the data - the low remote code would, either be locked into transfering raw bytes, or be forced to use the pack method Also, ... In my way earlier post, I also suggested "remote I/O' - a generic mechanism for accessing arbitrary target data. Looking through the target vectore I see there is already "to_query()". The original intent of to_query was to handle exactly this sort of problem - pushing data anonymously through the target vector. The auxv fetch, with a large bit of a struggle, could even be implemented using to_query. So? I've strong reservations towards adding redundant functionality to the target vector. However, I also note that the existing to_query method isn't sufficient. So I can see either an iterator, or an update to to_query being added to the target vector. Given that the iterator is a given, that might be the safest starting point - let the target maintainer go through and clean up to_query. thoughts, Andrew