mirror of
https://github.com/Zenithsiz/ftmemsim-valgrind.git
synced 2026-02-08 21:09:49 +00:00
d457604d49
Some applications are mapping an object ro, and then unmaps it directly. In such a case, we have a di that contains obsolete fsm.maps (not matching OS mappings). The di for this unmapped object is not active, and has no dinfo (have_dinfo == False). (more generally, fsm.maps can contain a whole bunch of obsolete mappings). Later on, some other libs can be mapped with a mapping overlapping this obsolete mapping. A di that never had its debug info loaded can really be discarded, even if CG_(clo_keep_debuginfo). In such a case, it is normal to have to discard a not active di. (it might be better to keep fsm.maps in sync with the real OS mapping, but that is a much bigger change/fix). The FSM debug tracing was static, it is now dynamic according to debug loglevel >= 3. The below is an extract of the trace showing what happens. SYSCALL[4384,1](257) sys_openat ( 4294967196, 0x4244398(/usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqeglfs.so), 524288 ) --> [async] ... SYSCALL[4384,1](257) ... [async] --> Success(0x3) SYSCALL[4384,1](72) sys_fcntl[ARG3=='arg'] ( 3, 2, 1 )[sync] --> Success(0x0) SYSCALL[4384,1](5) sys_newfstat ( 3, 0x1ffefff8b0 )[sync] --> Success(0x0) SYSCALL[4384,1](5) sys_newfstat ( 3, 0x1ffefff9c0 )[sync] --> Success(0x0) SYSCALL[4384,1](9) sys_mmap ( 0x0, 10520, 1, 1, 3, 0 )--4384-- di_notify_mmap-0: --4384-- di_notify_mmap-1: 0x4027000-0x4029fff r-- --4384-- di_notify_mmap-2: /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqeglfs.so --4384-- di_notify_mmap-3: is_rx_map 0, is_rw_map 0, is_ro_map 1 --4384-- di_notify_mmap-4: noting details in DebugInfo* at 0x10024CEA10 --4384-- di_notify_mmap-6: no dinfo loaded /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqeglfs.so (no rx or no rw mapping) --> [pre-success] Success(0x4027000) SYSCALL[4384,1](3) sys_close ( 3 )[sync] --> Success(0x0) SYSCALL[4384,1](11) sys_munmap ( 0x4027000, 10520 )[sync] --> Success(0x0) ^^^^ the above munmap has not cleaned up or removed anything in DebugInfo* at 0x10024CEA10 Later on, /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so is mapped overlapping the memory where libqeglfs.so was mapped ro. Now, this cleans up the (useless) di that never had have_dinfo true, e.g. ------ start ELF OBJECT ------------------------------------------------------- ------ name = /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so ... --4384-- Discarding syms at 0x0-0x0 in /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqeglfs.so (have_dinfo 0) (the 0x0-0x0 in the trace is because there was never any text mapping for libqeglfs.so).
On 4 Apr 06, the debuginfo reader (m_debuginfo) was majorly cleaned up
and restructured. It has been a bit of a tangle for a while. On 18 Sep 14
the STABS support was completely removed. The new structure looks like this:
debuginfo.c
readelf.c
readdwarf.c
storage.c
Each .c can only call those below it on the page.
storage.c contains the SegInfo structure and stuff for
maintaining/searching arrays of symbols, line-numbers, and Dwarf CF
info records.
readdwarf.c parses the relevant kind of info and call storage.c to
store the results.
readelf.c reads ELF format, hands syms directly to storage.c,
then delegates to readdwarf.c for debug info. All straightforward.
debuginfo.c is the top-level file, and is quite small.
There are 2 goals to this:
(1) Generally tidy up something which needs tidying up
(2) Introduce more modularity, so as to make it easier to add
readers for other formats, if needed
Rationale for (1) and (2) are obvious.
Originally there was also goal (3) Simplify the stabs reader.
But stabs support was broken since 3.9.0 and completely removed in 3.10.0.
The worst thing is that it is the stabs type reader that was crashing,
not the stabs line-number reader.
Old versions of the stabs type reader can be found in the subversion repository
as m_debuginfo/UNUSED_STABS.txt, the stabs line-number reader was in
m_debuginfo/readstabs.c. The old version of this file explained more
about the setup.