From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32597 invoked by alias); 7 Oct 2003 04:07:56 -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 32590 invoked from network); 7 Oct 2003 04:07:55 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 7 Oct 2003 04:07:55 -0000 Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian)) id 1A6j8c-00011g-Ia for ; Tue, 07 Oct 2003 00:07:54 -0400 Date: Tue, 07 Oct 2003 04:07:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: unwind support for Linux 2.6 vsyscall DSO Message-ID: <20031007040754.GA32257@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <200310070013.h970Ddai032605@magilla.sf.frob.com> <3F8238B0.50409@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F8238B0.50409@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-10/txt/msg00159.txt.bz2 On Mon, Oct 06, 2003 at 11:53:20PM -0400, Andrew Cagney wrote: > >>> 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 I think a pack method is overengineered. Unlike, for instance, register files, we never need to pack an arbitrary auxv array. We're always just copying one that we've been given, exactly as-is. I just see call for transport and query. > 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. Hmm, yes. The only problem that I see is the buffer-sizing one. A traditional problem in our interfaces, I think; the remote code avoids the issue delicately. > 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. While I won't argue about an iterator being useful, I think that the target vector code would be clearer if we just had the raw buffer. Layer the iterator on top of it, instead of re-implementing the iterator in every target. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer