From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10924 invoked by alias); 7 Oct 2003 02:30:48 -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 10577 invoked from network); 7 Oct 2003 02:30:45 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 7 Oct 2003 02:30:45 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h972Ui130733 for ; Mon, 6 Oct 2003 22:30:44 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h972Uic29835 for ; Mon, 6 Oct 2003 22:30:44 -0400 Received: from localhost.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id h972Uhbe015483; Mon, 6 Oct 2003 22:30:43 -0400 Received: by localhost.redhat.com (Postfix, from userid 469) id A1F532CC88; Mon, 6 Oct 2003 22:41:31 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16258.10202.899788.703135@localhost.redhat.com> Date: Tue, 07 Oct 2003 02:30:00 -0000 To: Roland McGrath Cc: Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: unwind support for Linux 2.6 vsyscall DSO In-Reply-To: <200310070013.h970Ddai032605@magilla.sf.frob.com> References: <200310062359.h96Nxqgt032566@magilla.sf.frob.com> <200310070013.h970Ddai032605@magilla.sf.frob.com> X-SW-Source: 2003-10/txt/msg00153.txt.bz2 Roland McGrath writes: > > > 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. > It is useful if you want to apply a specific function to the entries of the auxv vectors in a generic way while iterating. There are plenty of other examples in gdb and bfd where this interface is used, albeit it may not be the most efficient. I think you could still write an iterator because it will be needed. > 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 the corefile case.