From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32144 invoked by alias); 7 Oct 2003 00:13:41 -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 32137 invoked from network); 7 Oct 2003 00:13:41 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.81.54.130) by sources.redhat.com with SMTP; 7 Oct 2003 00:13:41 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 2A09E357B; Mon, 6 Oct 2003 17:13:40 -0700 (PDT) Received: from magilla.sf.frob.com (localhost.localdomain [127.0.0.1]) by magilla.sf.frob.com (8.12.9/8.12.9) with ESMTP id h970DdN2032609; Mon, 6 Oct 2003 17:13:39 -0700 Received: (from roland@localhost) by magilla.sf.frob.com (8.12.9/8.12.9/Submit) id h970Ddai032605; Mon, 6 Oct 2003 17:13:39 -0700 Date: Tue, 07 Oct 2003 00:13:00 -0000 Message-Id: <200310070013.h970Ddai032605@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: unwind support for Linux 2.6 vsyscall DSO In-Reply-To: Roland McGrath's message of Monday, 6 October 2003 16:59:52 -0700 <200310062359.h96Nxqgt032566@magilla.sf.frob.com> Emacs: the road to Hell is paved with extensibility. X-SW-Source: 2003-10/txt/msg00141.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.