Re: bfd function to read ELF file image from memory

[Nick Clifton <nickc@redhat.com>]

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