docs/internals/segments-seginfos.txt

-----------------------------------------------------------------------------
Info about the relationship between Segments and SegInfos
-----------------------------------------------------------------------------

SegInfo is from the very original Valgrind code, and so it predates
Segments.  It's poorly named now; its really just a container for all
the object file metadata (symbols, debug info, etc).

Segments describe memory mapped into the address space, and so any
address-space chaging operation needs to update the Segment structure.
After the process is initalized, this means one of:

    * mmap
    * munmap
    * mprotect
    * brk
    * stack growth

A piece of address space may or may not be mmaped from a file.

A SegInfo specifically describes memory mmaped from an ELF object file.
Because a single ELF file may be mmaped with multiple Segments, multiple
Segments can point to one Seginfo.  A SegInfo can relate to a memory
range which is not yet mmaped.  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.  If a new mmap
appears in the address range of an existing SegInfo, it will have that
SegInfo attached to it, presumably because its part of a .so file.
Similarly, if a Segment gets split (by mprotect, for example), the two
pieces will still be associated with the same SegInfo.  For this reason,
the address/length info in a SegInfo is not a duplicate of the Segment
address/length.

This is complex for several reasons:

   1. We assume that if a process is mmaping a file which contains an
      ELF header, it intends to use it as an ELF object.  If a program
      which just mmaps ELF files but just uses it as raw data (copy, for
      example), we still treat it as a shared-library opening.
   2. Even if it is being loaded as a shared library/other ELF object,
      Valgrind doesn't control the mmaps.  It just observes the mmaps
      being generated by the client and has to cope.  One of the reasons
      that Valgrind has to make its own mmap of each .so for reading
      symtab information is because the client won't necessary mmap the
      right pieces, or do so in the wrong order for us.

SegInfos are reference counted, and freed when no Segments point to them any
more.

> Aha.  So the range of a SegInfo will always be equal to or greater
> than the range of its parent Segment?  Or can you eg. mmap a whole
> file plus some extra pages, and then the SegInfo won't cover the extra
> part of the range?

That would be unusual, but possible.  You could imagine ld generating an
ELF file via a mapping this way (which would probably upset Valgrind no
end).