PATCH: provide pass-through value in bfd_elf_bfd_from_remote_memory

[Jim Blandy]

Roland McGrath <roland@redhat.com> writes:

> > Yes, but while you're there can the can you please also expunge that 
> > ehdr_vma parameter so that this uses a normal read() function that takes 
> > an offset.
> 
> The function in question reads from inferior virtual memory addresses, not
> positions in any file.  EHDR_VMA is needed not only to locate the ELF
> header for reading, but to do other address calculations in making sense of
> the data.  

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?

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.  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, to get
them in the right relative positions specified by their p_vaddrs.  In
other words, for a "loaded" vsyscall DSO, there *is* a single offset O
of the sort I described above.  Right?

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

This means that you don't need to do anything funny with EHDR_VMA:
it's just an offset that you add to every address you pass to
TARGET_READ_MEMORY.  So you might as well omit the argument, and let
target_read_memory add the offsets for you.  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.

I'm also confused by the way loadbase is computed:

  loadbase = ehdr_vma;
  ...
	  if ((i_phdrs[i].p_offset & -i_phdrs[i].p_align) == 0)
	    loadbase = ehdr_vma - (i_phdrs[i].p_vaddr & -i_phdrs[i].p_align);

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.