--- Begin Message ---
- From: Andrew Cagney <cagney at gnu dot org>
- To: binutils at sources dot redhat dot com
- Date: Mon, 03 May 2004 18:32:26 -0400
- Subject: New bfd file format bfd_image ....
- Delivery-date: Mon, 03 May 2004 18:39:56 -0400
- Envelope-to: cagney@gnu.org
Hello,
Not so recently the bfd open method:
/* Create a new BFD as if by bfd_openr. Rather than opening a file,
reconstruct an ELF file by reading the segments out of remote memory
based on the ELF file header at EHDR_VMA and the ELF program headers it
points to. If not null, *LOADBASEP is filled in with the difference
between the VMAs from which the segments were read, and the VMAs the
file headers (and hence BFD's idea of each section's VMA) put them at.
The function TARGET_READ_MEMORY is called to copy LEN bytes from the
remote memory at target address VMA into the local buffer at MYADDR; it
should return zero on success or an `errno' code on failure. TEMPL must
be a BFD for an ELF target with the word size and byte order found in
the remote memory. */
extern bfd *bfd_elf_bfd_from_remote_memory
(bfd *templ, bfd_vma ehdr_vma, bfd_vma *loadbasep,
int (*target_read_memory) (bfd_vma vma, char *myaddr, int len));
was added. It's there to let GDB create a BFD corresponding to an
in-memory image of an object file. This in turn being needed by GDB to
open/extract GNU/Linux's vsyscall page.
Now that GDB's started trying to use it, it enountered an itegration
problem - the code leads to a hard-wired assumption that there's elf in
bfd vis:
http://sources.redhat.com/ml/gdb/2004-04/msg00140.html
I'd like to propose that BFD add a new ``file format'' ``image'' (better
name welcome) that more closely reflects what is going on here.
Given an ``image'', it would then be possible to open a bfd using the
more traditional sequence:
abfd = bfd_open... (memory image)
bfd_check_format (abfd, bfd_image)
Rather than talk theory, I've prototyped the idea and found the exact
sequence is like:
+ nbfd = bfd_openr_iovec ("shared object read from target memory",
+ gnutarget, inf_open, NULL,
+ inf_pread, inf_close);
+ /* Use start_address to tunnel the address of the ELF header through
+ to the check-format code. */
+ bfd_set_start_address (nbfd, elf_header_addr);
+ if (!bfd_check_format (nbfd, bfd_image))
creating NBFD with what looks like a normal elf BFD object.
The prototype identified the following issues:
- the theory appears sound
It should be possible to feed libbfd a memory image and the address of
an in-memory executable header and have it return a BFD. It would, for
instance, open the possability of doing things like:
objdump --flags -h /proc/$$/mem
to get a dump of whats in part of a memory image.
- there's a problem tunneling the address of the in-memory elf header
The inital bfd_open results in a BFD that has access to the entire
in-memory image. For check_format (bfd_elf_image_p) to parse the elf
header it needs that header's address (ok header's file offset). In my
prototype I tunneled the address of the elf header by storing it in
start_address. Something else is needed. One thought was:
abfd = bfd_open
bfd_seek (abfd, header_address, SEEK_SET)
bfd_check_format (....)
only bfd_check_format does a seek(0) before probing the format. Another
thought was to use a filed like:
abfd->origin
comments?
- there's a problem passing back LMA vs VMA
The image, as with a shared library, can be re-located by a constant
offset. I returned this information using section.lma, not sure if its
a good idea (but it's not a bad idea).
- the final BFD looks like a file not memory
I (as did roland before me) convert the memory image into something that
more closely resembles the original file. This was easier then trying
to reproduce the code needed to create BFD that retains the old memory
image (leave that as a very long term goal).
comments, thoughts, suggestions, worth trying to integrate?
Andrew
--- End Message ---