getting vDSO image into libdwfl

[Roland McGrath <roland@redhat.com>]

The normal kinds of modules in a process (or a kernel) correspond to ELF
files on disk.  We satisfy the Dwfl_Callbacks.find_elf callback for those
just by opening the file by name.  The vDSO does not exist as a file on
disk, so we need to read the ELF file image directly from memory in the
debuggee address space.

The find_elf callback normally supplies a file name and most often an fd.
But it can also supply an Elf * handle already opened, and then the file
name and fd are not required.  So, a find_elf callback dealing with the
vDSO module can get a copy of the vDSO image from the debugee address space
into local memory in the debugger and use elf_memory to create an Elf *
handle on it.

The dwfl_linux_proc_find_elf callback does this as a skeletal example.
It uses this function (see libdwfl/elf-from-memory.c):

    /* 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 addresses from which the segments were read, and the
       addresses the file headers put them at.

       The function READ_MEMORY is called to copy at least MINREAD and at most
       MAXREAD bytes from the remote memory at target address ADDRESS into the
       local buffer at DATA; it should return -1 for errors (with code in
       `errno'), 0 if it failed to read at least MINREAD bytes due to EOF, or
       the number of bytes read if >= MINREAD.  ARG is passed through.  */

    Elf *
    elf_from_remote_memory (GElf_Addr ehdr_vma,
			    GElf_Addr *loadbasep,
			    ssize_t (*read_memory) (void *arg, void *data,
						    GElf_Addr address,
						    size_t minread,
						    size_t maxread),
			    void *arg)

This is an internal function not exported in the DSO or declared anywhere.
I wrote it as the necessary and separable component (and analogous to the
BFD function bfd_elf_bfd_from_remote_memory I added for the gdb vDSO
support).  I tested it via dwfl_linux_proc_find_elf (-p option to
eu-addr2line et al).  (Back then, /proc/PID/mem had not been made so
"secure", so it even worked in eu-foo without ptrace.)  I figured the
details of interface to that code and how it integrates with everything
would be ironed out when a real user came along.  Now here we are.

If you read the function, you'll see a lot of libelf hooey to deal with the
format encoding in all cross-permutations, but it's not doing very much.
It just reads the ELF file header and phdrs enough to decide if the whole
file image is really in memory and exactly how big it is.  Then it reads it
all in, and calls elf_memory.

The signature of the read_memory callback is arbitrary.  
It just seemed like the roughly appropriate general thing.
It's easy to change.

This function doesn't really fit with the libelf interfaces.  It could be
exposed by libdwfl in some fashion I suppose.  I hadn't really figured out
what seemed right, which is why it's as it is.  I could just change its
name and signature slightly, and export it from libdwfl.

Alternatively, if you have Java libelf bindings for all the xlate stuff,
it's not very complex to code it up in Java.  Then you might have a cleaner
way to integrate the memory-reading stuff that might do less copying.
Maybe some existing buffer data structure of yours has a raw pointer you
can pass to elf_memory.

Finally, you can instead avoid all this ELF grovelling stuff altogether.
This certainly seems like simplest thing for Frysk to do to start with, so
naturally I mention it last.  All the ELF header grokking is basically to
determine how big the image is (and in the general case that does not apply
here, if the phdrs really say that the memory image matches the whole file).
You already know how big the mapping is (in practice so far always one page,
two on ia64, might be a few on ppc).  That's the page-rounded upper limit on
the size of the image.  On x86, the mapping is 4k (one page) and the vDSO
ELF file image is actually between 2k and 3k.  Past the end of the actual
image, the rest of the page is zero.  It doesn't hurt to give elf_memory a
buffer including this padding.  So if it's not too costly to read a whole
page of memory instead of 1/2 or 3/4 that much, you can just do that.


Thanks,
Roland