Re: PATCH: provide pass-through value in bfd_elf_bfd_from_remote_memory

[Roland McGrath <roland at redhat dot com>]

> For a normal, loaded shared library, segments might have different
> *relative* positions in the file and in memory.  There's a single base
> address for the loaded library that gives the offset from every
> segment's p_vaddr in the file to its loaded address, but there is not
> necessarily a single offset O from every segment's p_offset to its
> loaded address.  Right?

Correct.

> But the vsyscall DSO is more restricted than your normal loaded shared
> library: it's actually the real image of an ELF file, mapped directly
> into memory.

Well, you can describe it that way.  But it's not actually a special case,
as this makes it out to be.  It's an ELF file that has only one segment and
that segment's p_offset is 0.

> If one were loading it with mmap (and ignoring segment permissions), it
> could always be done with a single mmap call, unlike real shlibs, which
> might require a separate mmap per segment, 

There is only one segment, so a separate mmap per segment vs a single mmap
is a meaningless distinction.

> In other words, for a "loaded" vsyscall DSO, there *is* a single offset Op
> of the sort I described above.  Right?

It's certainly true that in the case that there is only one segment and its
p_offset is 0, offsets from the beginning of the segment and the beginning
of the ELF file mean the same thing.  

> That's why it makes sense to ask BFD to parse it, rather than some
> specialized tool: BFD's assumptions all hold, except for where the
> data is coming from.  

It makes sense to ask BFD to parse it because what's constructed is a valid
ELF file image, and BFD is something that knows how to parse those.

> So EHDR_VMA must be the difference between every segment's offset in the
> ELF "file" to its address in whatever space TARGET_READ_MEMORY accesses.

No.  It's the VMA of where the ELF header appears in memory, just like it
says.  Many of your comments relate meaningfully to the first
implementation of this function that I posted.  That is why that first
posting included a paragraph discussing the entire question in detail, and
explaining how a different implementation based on phdrs is what makes
sense for the general case.  As my followup posting with the new code said,
I rewrote the function to behave that way and that is what you see now.

> But your code does something more complex, so that must be a bug, at
> least in the docs: if it's not loaded that way --- a byte-for-byte image
> of an ELF file that just happens to be in memory --- then the
> documentation really needs to explain how everything is laid out.

There is no bug, and it does exactly what the documentation says.  To wit:

   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.

Here "segment" means what it means in all ELF-related documentation.
Segments are described by phdrs, and exist both in memory and in the file.
The only relationship between the memory addresses (p_vaddr) and the file
positions (p_offset) is their congruence modulo segment alignment (p_align).

Here "remote memory" means what you get by calling target_read_memory,
which one can reasonably infer from the second paragraph of the comment:

   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 reads the remote memory addresses indicated by the ELF program headers'
p_vaddr fields.

Here "an ELF file" refers to the file image that is constructed in the
buffer allocated and stored in abfd->contents for access by bfd_bread et
al.  It stores the segment contents in this buffer at the offsets indicated
by the ELF program headers' p_offset fields.

Thus it reconstructs an ELF file by reading the segments out of remote
memory based on the ELF file header and the ELF program headers it points to.

What else can I say?  The comments make sense to me as they are, and all
I've said in explaining them to you is to repeat what they say, and cite a
few fundamental details of the ELF format.  I have no basis upon which to
speculate what different form of presentation would make sense to other
people, having to my knowledge only ever been myself.  If you have
different comments that make more sense to you and are not inaccurate,
then by all means put them in.

> If the ELF file doesn't have a load segment which includes the ELF
> header, it seems like you have no reason to assume that EHDR_VMA has
> any particular relationship to any segment's loaded vma.

This case cannot possibly be covered at all by this function.  If the ELF
header was not loaded at the address given by EHDR_VMA, there is nothing to
do.  Intermediate versions of this function kind of sort of supported cases
where the segments were not entirely reasonable, but the present
implementation really doesn't.  It would be reasonable to add a sanity check
rather than the loadbase=ehdr_vma default that doesn't really make sense
any more.