From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15233 invoked by alias); 16 May 2003 11:24:36 -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 9425 invoked from network); 16 May 2003 11:20:28 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 16 May 2003 11:20:28 -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 h4GBKSH23859; Fri, 16 May 2003 07:20:28 -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 h4GBKSI23787; Fri, 16 May 2003 07:20:28 -0400 Received: from localhost.localdomain.redhat.com (vpn50-1.rdu.redhat.com [172.16.50.1]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h4GBJkQ09854; Fri, 16 May 2003 07:20:11 -0400 To: Roland McGrath Cc: binutils@sources.redhat.com, gdb-patches@sources.redhat.com Subject: Re: bfd function to read ELF file image from memory References: <200305140128.h4E1Spw06177@magilla.sf.frob.com> From: Nick Clifton Date: Fri, 16 May 2003 11:24:00 -0000 In-Reply-To: <200305140128.h4E1Spw06177@magilla.sf.frob.com> (Roland McGrath's message of "Tue, 13 May 2003 18:28:51 -0700") Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-05/txt/msg00274.txt.bz2 Hi Roland, > But all of that is a bit of a digression. I'm posting now because I > don't quite know where to put this function even it its > implementation were perfect. It was by far easier to write it in > elfcode.h than to put it elsewhere. It gets to use the local helper > code there, and automagically define 32 and 64 bit flavors, which > keeps the code quite simple. It would be a lot more hair to put the > code elsewhere, copy the header swapping code, and do the 32/64 > versions half as cleanly. > > The proper way to put it there is to make it yet another bfd target > vector function. I don't know what all rigamorole is involved in > doing that, and it seems like overkill for something probably only > ever used by gdb and only with ELF. Well since your function is creating a new bfd, one obvious place for it would be in opncls.c. Have you considered using an interface like the one provided by BFD_IN_MEMORY ? You could make the in-memory interface generic and provide different memory accessing functions (for local memory, remote memory, mmap'ed files, etc). I do not think that treating this in-memory bfd as a new target is appropriate, since it is not really a new file format or instruction set architecture, but a new method of loading (part of) a binary file into a normal bfd structure. > Can anyone offer advice on where this function ought to live? If it > doesn't live in the bfd elf backend, then I'll have to copy or > hand-integrate some sanity checking and byte-swapping code for ELF > headers. I am all for keeping things simple, so if it is easier to put it in elfcode.h then that is probably where it should live. Given the probably limited utility of this function it probably ought to be only conditionally defined, based on the particular configured target or maybe a configure time switch. Cheers Nick