[Valgrind-developers] Debug info loading requirements

[Julian S. <js...@ac...>]

Starting to consider symbol loading on the aspacem branch.

I looked at docs/internals/segments-seginfos.txt, and studied the
associated code a bit, and I think I see what's going on.

What I can't figure out is whether such a complex approach is
really needed.  I realise that the question "should we load=20
symbols for the mmap that just happened" can't be answered=20
exactly, because there is no surefire way to distinguish an
mmap done by ld.so(dlopen) vs some random mmap of an object file
which just happens to look indistinguishable.  However clever
we are, a sufficiently devious program can always fool us into
not loading debuginfo when we should, or vice versa. =20
I don't feel there's much point in trying to correctly handle
anything other than the bog-standard nothing-weird case.

It would be useful to enumerate the cases which happen in
practice.  segments-seginfos.txt contains a couple of comments
in support of the reference counting scheme:

> Similarly, if a Segment gets split (by mprotect, for example), the two
> pieces will still be associated with the same SegInfo.

> If a new mmap appears in the address range of an existing SegInfo

Do either of these happen in practice?

> For example, if the process mmaps the
> first page of an ELF file (the one containing the header), a SegInfo
> will be created for that ELF file's mappings, which will include memory
> which will be later mmaped by the client's ELF loader.

I wasn't clear what is supposed to happen here.

=2D-----------

=46rom peering at various /proc/*/maps files, the following scheme
sounds plausible:

Load symbols following an mmap if:

  map is to a file
  map has r-x permissions
  file has a valid ELF header
  possibly: mapping is > 1 page (catches the case of mapping first
     page just to examine the header)

If the client wants to subsequently chop up the mapping, or change its
permissions, we ignore that.  I have never seen any evidence in proc/*/maps
that ld.so does such things.

=46ollowing an munmap, dump symbols for any previously loaded range
which intersects the unmapped range.  Again, this screws up if half an
executable segment is unmapped, and again I'm not sure this happens in
practice.

=46ollowing an mprotect, dump symbols for any previously loaded range
which intersects the protected range AND the new protection does not
include 'x' access.

=2D-----------

Any ideas if something this simple would work (before I find out
the hard way? :-)  IIRC 1.0.X had an even more moronic scheme and I
don't remember people complaining about it, although equally it
could have had problems with corner cases / unusual uses=20
that I wasn't aware of.

J