vdso handling

Mark Wielaard mjw@redhat.com
Thu Mar 13 14:38:00 GMT 2014

On Thu, 2014-03-13 at 23:33 +1030, Alan Modra wrote:
> On Thu, Mar 13, 2014 at 10:52:16AM +0100, Mark Wielaard wrote:
> > On Thu, 2014-03-13 at 11:31 +1030, Alan Modra wrote:
> > > It wouldn't
> > > help in the vdso case anyway, since the problem there is that you only
> > > have the loaded part of the original ELF file.
> > 
> > Note that the vdso is often special, compared to other ELF dsos, because
> > the loaded part is just the complete ELF image in memory. Since they are
> > very simple they will just have one PT_LOAD at offset zero and if the
> > image is smaller than the page size then the whole file is just simply
> > mapped into memory completely. So by fetching the vdso ELF image from
> > remote memory you should be able to get the section headers and the
> > not-allocated sections too.
> Yes, but if the vdso does not fit in a page (which incidentally is
> inferred by program header p_align), then you may lose the section
> headers.  I was assuming this was the case.

Yes, you are right. Almost everything else is bigger than a page and has
multiple PT_LOAD segments. In which case determining whether the full
shdrs were mapped in from the file is much trickier. And might have to
rely on only the phdrs.

We recently went through this for elfutils, which also contains an
elf_from_remote_memory implementation (if someone needs inspiration).
Currently that implementation just uses the phdrs and so needs some
heuristics using the program header fields to know what part of the file
was mapped where. But if you have access to the actual /proc/PID/maps
ranges you might be able to do something more accurate, or at least be
able to cross check that the program headers view is really how the ELF
image is actually laid out (*).



(*) Don't make the mistake we made to think p_align is what segments are
actually aligned to, the dynamic loader on GNU/Linux just uses the
actual page size of the architecture to align the mappings:

More information about the Gdb mailing list