From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5063 invoked by alias); 17 May 2003 05:39: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 4784 invoked from network); 17 May 2003 05:39:40 -0000 Received: from unknown (HELO localhost.redhat.com) (24.157.166.107) by sources.redhat.com with SMTP; 17 May 2003 05:39:40 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 49BB22B2F; Sat, 17 May 2003 01:39:27 -0400 (EDT) Message-ID: <3EC5CB0F.7060502@redhat.com> Date: Sat, 17 May 2003 05:39:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nick Clifton Cc: Roland McGrath , 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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg00302.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). That sounds right. It lets BFD create a bfd using an arbitrary [memory] read (or even memory map) function. It may also open the way for mmaping the entire executable and then creating a bfd pointing at that (assuming that isn't yet possible :-). > 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. Yes. >> 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. It could go in a separate file? That way, if *-pc-linux-gnu-gdb needs it, it will link it in. However, seriously, if bfd did have a generic and clean memory map interface I think people would use it. Andrew PS: To explain what's, er, gone wrong Recent Linux kernel's have taken to including an entire ELF object in the target process's address space (the object file comes from the Kernel and is not part of the file system). You'll see it refered to as the vsyscall region. It appears that GDB is going to need to open this in target memory (or in core) object, as GDB needs things from it (such as .eh_frame info) if GDB is to manage to unwind from a syscall. Just in case you're getting any false impressions over the current status of GDB, nothing has really resolved. Right now, the kernel/core file don't even provide the address of the above beastie (It's been suggested on gdb@ that the Kernel provide it via /proc/PID/auxv and a .note in the core file, but don't know if it's been taken to the kernel list. Hmm, dig dig, http://www.ussg.iu.edu/hypermail/linux/kernel/0305.1/2566.html seems Roland is following it through but forgot to advice the GDB group.