Re: vdso handling

[Alan Modra <amodra@gmail.com>]

On Wed, Mar 19, 2014 at 12:03:40PM +0000, Pedro Alves wrote:
> On 03/18/2014 11:09 PM, Alan Modra wrote:
> > I don't think this is a good idea.  If/when bfd_from_remote_memory is
> > used for something other than the linux kernel vdso, we can't assume
> > the section headers are loaded.  
> 
> I wonder what use cases are these though.  It'd be odd to me to
> load the elf headers, but not all that the headers point at.

Well, no, the section headers are part of the linking view.  The ELF
file header points at their *file offset*.  Thinking it odd that they
are not loaded is exactly the same as thinking it odd that .comment is
not loaded!

> Sounds like we should just make that a requirement?

You indeed could make that a requirement, but it'd mean that object
files loaded by glibc ld.so would not satisfy the requirement.

Taking Markus' vdso as an example, the PT_LOAD header covers file
offsets from 0 to 0xffd and page size is 0x1000.  If ld.so were
loading a similar image, it would just load in 0 to 0xfff (assuming
ld.so's dl_pagesize is also 0x1000).  The section headers are at file
offset 0x10e0 so would miss being loaded.  Nor should they be loaded,
since they are completely extraneous to executing the image it would
be foolish to waste another page to load them.

>  "This command may not really be worth having, but it serves to exercise the
>  underlying function symbol_file_add_from_memory.  That function does the
>  work of reading symbols and unwind info from the Linux vsyscall DSO."

Heh, OK, so don't let my comments about more general uses of
bfd_from_remote_memory get in your way of fixing this problem.

Hmm, if you only want to read vdsos then bfd_from_remote_memory is way
overengineered.  In fact, I think it could disappear entirely.
If you can find the extent of the vdso in gdb, then all of the ELF
version of bfd_from_remote_memory prior to allocating the bim is
unnecessary, because all that code really does is find the extent.
So the tail of bfd_from_remote_memory moves to bfd/opncls.c as
(totally untested):

bfd_boolean
bfd_openr_bim (bfd *templ, void *contents, size_t contents_size)
{
  struct bfd_in_memory *bim;

  bim = (struct bfd_in_memory *) bfd_malloc (sizeof (struct bfd_in_memory));
  if (bim == NULL)
    return NULL;

  nbfd = _bfd_new_bfd ();
  if (nbfd == NULL)
    {
      free (bim);
      return NULL;
    }
  nbfd->filename = "<in-memory>";
  if (templ != NULL)
    nbfd->xvec = templ->xvec;
  bim->size = contents_size;
  bim->buffer = (bfd_byte *) contents;
  nbfd->iostream = bim;
  nbfd->flags = BFD_IN_MEMORY;
  nbfd->iovec = &_bfd_memory_iovec;
  nbfd->origin = 0;
  nbfd->direction = read_direction;
  nbfd->mtime = time (NULL);
  nbfd->mtime_set = TRUE;
  return nbfd;
}

gdb is then responsible for filling in "contents" and determining
"contents_size", which presumably can be done in the same way as
you did in https://sourceware.org/ml/binutils/2014-03/msg00130.html
The loadbase calculation also moves to gdb, which shouldn't be too
hard.  Note that "templ" above is optional, which allows you to get
rid of
       /* FIXME: cagney/2004-05-06: Should not require an existing
         BFD when trying to create a run-time BFD of the VSYSCALL

-- 
Alan Modra
Australia Development Lab, IBM