----------------------------------------------------------------------------- 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). ----------------------------------------------------------------------------- More from John Reiser ----------------------------------------------------------------------------- > Can a Segment get split (eg. by mprotect)? This happens when a debugger inserts a breakpoint, or when ld-linux relocates a module that has DT_TEXTREL, or when a co-resident monitor rewrites some instructions. On x86, a shared lib with relocations to .text "works" just fine. The modified pages are no longer sharable, but the instruction stream is functional. It's even rather common, when a builder forgets to use -fpic for one or more files. It can be done on purpose when the modularity is more important than the page sharing. Non-pic code is faster, too: register %ebx is not dedicated to _GLOBAL_OFFSET_TABLE_ addressing, and global variables can be accessed by [relocated] inline 32-bit offset rather than by address fetched from the GOT. > Can a new mmap appear in the address range of an existing SegInfo? On x86_64 the static linker ld inserts a 1MB "hole" between .text and .data. This is on advice from the hardware performance mavens, because various caching+prefetching hardware can look ahead that far. Currently ld-linux leaves this as PROT_NONE, but anybody else is free to override that assignment. > From 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. glibc-2.3.5 ld-linux does. It finds the minimum interval of pages which covers the p_memsz of all PT_LOAD, mmap()s that much from the file [even if this maps beyond EOF of the file], then munmap()s [or mprotect(,,PROT_NONE)] everything that is not covered by the first PT_LOAD, then mmap(,,,MAP_FIXED,,) each remaining PT_LOAD. This is done to overcome the possibility that a kernel which randomizes the placement of mmap(0, ...) might place the first PT_LOAD so that subsequent PT_LOAD [must maintain relative addressing to other PT_LOAD from the same file] would evict something else. Needless to say, ld-linux assumes that it is the only actor (well, dlopen() does try for mutual exclusion) and that any "holes" between PT_LOAD from the same module are ignorable as far as allocation is concerned. Also, there is nothing to stop a file from having PT_LOAD that overlap, or appear in non-ascending order, etc. The results might depend on order of processing, but always it has been by order of appearance in the file. [Probably this is a good way to trigger "bugs" in ld-linux and/or the kernel.] Some algorithms and data structures internal to glibc-2.3.5 assume that modules do not overlap. In particular, ld-linux sometimes searches for __builtin_return_address_(0) in a set of intervals in order to determine which shared lib called ld-linux. This matters for dlsym(), dlmopen(), etc., and assumes that the intervals are a disjoint cover of any "legal" callers. ld-linux tries to hide all of this from the prying eyes of anyone else [the internal version of struct link_map contains much more than specified in ]. Some of this is good because it changes very frequently, but some parts are bad because in the past ld-linux has been slow to provide needed services [such as dl_iterate_phdr()] and even antagonistic towards anybody else trying for peaceful co-existence without the blessing of ld-linux.