RE: vdso handling

["Metzger, Markus T" <markus dot t dot metzger at intel dot com>]

> -----Original Message-----
> From: Alan Modra [mailto:amodra@gmail.com]
> Sent: Thursday, March 20, 2014 2:33 AM


> 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

I was waiting for Pedro to reply but he didn't.

This would move the ELF processing itself into GDB.  That sounds a bit
odd to me but it seems GDB already does a fair amount of ELF reading.

Pedro, are you OK with this?  Will you accept a patch that goes into
the direction that Alan described above?

Thanks,
Markus.
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052