Branch: refs/heads/thaines/symtab_remove_findModuleByName Home: https://github.com/dyninst/dyninst Commit: df3cb081af767ee5b32326c65174962828a00021 https://github.com/dyninst/dyninst/commit/df3cb081af767ee5b32326c65174962828a00021 Author: Tim Haines <thaines.as...@gmail.com> Date: 2023-10-09 (Mon, 09 Oct 2023)
Changed paths: M symtabAPI/doc/3-Examples.tex M symtabAPI/doc/API/LineInfo/Iterating.tex M symtabAPI/doc/API/Symtab/Symtab.tex M symtabAPI/h/Symtab.h M symtabAPI/src/Symtab-lookup.C M symtabAPI/src/Symtab.C Log Message: ----------- Remove Symtab::findModuleByName(Module *&, std::string) A Symtab::Module is a one-to-one mapping to a DWARF compilation unit (CU). In DWARF4, we consider a CU to be an entry in the .debug_info section with the tag DW_TAG_compile_unit. In DWARF5, we also include entries with the tag DW_TAG_partial_unit as they can contain symbol definitions; we assume libdw will merge all other split unit types for us. The name of a module is the DW_AT_name of the containing DIE. This is either the full path name of the source file used to create the CU or the relative path of the same with respect to the DW_AT_comp_dir. We ensure that the module's name is always an absolute path. Modules have never been required to have unique names. That is, many modules can share the same name. The following demonstrates this case: ``` test.c ------ void func1(){} void func2(){} $ gcc -g -c -DFUNC1 -o func1.o test.c $ gcc -g -c -DFUNC2 -o func2.o test.c $ gcc -g -fPIC -shared func1.o func2.o -o libfunc.so $ readelf --debug-dump=info libfunc.so | grep -A 6 DW_TAG_compile_unit <0><c>: Abbrev Number: 1 (DW_TAG_compile_unit) <d> DW_AT_producer : <redacted> <11> DW_AT_language : 29 (C11) <12> DW_AT_name : test.c <16> DW_AT_comp_dir : /path/to/test <1a> DW_AT_low_pc : 0x10f9 <22> DW_AT_high_pc : 0x1104 <0><55>: Abbrev Number: 1 (DW_TAG_compile_unit) <56> DW_AT_producer : <redacted> <5a> DW_AT_language : 29 (C11) <5b> DW_AT_name : test.c <5f> DW_AT_comp_dir : /path/to/test <63> DW_AT_low_pc : 0x1104 <6b> DW_AT_high_pc : 0x110F ``` Because the two CUs have the same name, Dyninst throws away the contents of the second one because this function would return the first. It is also possible (and likely) that the two CUs have different line maps and location lists. These, too, are discarded. Although unlikely, it is legal for a compiler to emit CUs with overlapping PC range values. This means the only was to uniquely identify a module is by its offset in the .debug_info section. _______________________________________________ Dyninst-api mailing list Dyninst-api@cs.wisc.edu https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api