From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8005 invoked by alias); 6 Oct 2003 19:35:42 -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 7987 invoked from network); 6 Oct 2003 19:35:41 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 6 Oct 2003 19:35:41 -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 h96JZf110771 for ; Mon, 6 Oct 2003 15:35:41 -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 h96JZfc18943 for ; Mon, 6 Oct 2003 15:35:41 -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 h96JZebe007032; Mon, 6 Oct 2003 15:35:40 -0400 Received: by localhost.redhat.com (Postfix, from userid 469) id 635A02CCA1; Mon, 6 Oct 2003 15:46:28 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16257.50836.244726.737208@localhost.redhat.com> Date: Mon, 06 Oct 2003 19:35:00 -0000 To: Jim Blandy Cc: Roland McGrath , gdb-patches@sources.redhat.com Subject: Re: unwind support for Linux 2.6 vsyscall DSO In-Reply-To: References: <200310040010.h940AhG5021281@magilla.sf.frob.com> X-SW-Source: 2003-10/txt/msg00116.txt.bz2 Jim Blandy writes: > > Roland McGrath writes: > > > BFD is overkill for this (not that I'm saying BFD isn't overkill for > > everything). There is no variation in the format among ELF flavors, it's > > just an even number of words in the format word size. The very notion of > > an auxilliary vector is ELF-specific; if a non-ELF backend had something > > useful to export in the way of an auxilliary data from somewhere extraction > > interface, it seems doubtful it would be a useful abstraction to call the > > two the same thing in the frontend interface. I don't have any objection > > to moving the parsing portion out somewhere else, but making it any more > > overblown than the few dozen lines of code it is would be pointless IMHO. > > Yeah, I had in mind another elf-specific BFD function, like the one > that reads the solib data from memory. All I'm suggesting is, take > the code that you've got, move it into bfd, and call it > bfd_elf_auxilliary_vector_sysinfo_ehdr. I disagree with moving the read of auxv to bfd. Gdb already processes plenty of /proc files (on Solaris using 2 interfaces), and has target methods defined for these, so I would treat the auxv case just like the others. elena