bfd function to read ELF file image from memory

[Andrew Cagney]

> 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.