Hi Sasha, On Tue, 2020-06-23 at 16:34 +0000, Sasha Da Rocha Pinheiro wrote: > Since we are now using not only executables and .so, but ".o" files > too, I'm trying to decide if I can use the same functions to all of > them, like the code you pointed out to deal with ".o". Would that > work for EXEC, SHARED, and RELOC?
Yes, it would work. The relocation resolving logic only triggers for .o (ET_REL) files. But everything else works as expected also for ET_EXEC and ET_DYN files. > The idea is not to have two codes to parse modules and DIEs, two ways > because as you pointed out ".o" files need some relocation to be > performed, therefore using dwfl_*. Meanwhile for executables and .so > we only use dwarf_* functions. > In face of that, do you foresee bigger changes or things we should > worry that we would have in case we use only dwfl_* to open all the > ELF files with dwarf data, and drop the way we used to open them? > Because our code base for a long time has only used the dwarf_* > functions, this would be a big change. The real "value" from the Dwfl interface comes from it trying to layout objects as if dynamically loaded. So you can mimic a process even if it isn't loaded (or a kernel plus modules). This is why some functions return an "bias" indicating the difference between the Dwfl_Module "assigned" addresses and any addresses you might read directly from the Elf or Dwarf. But you can of course ignore that functionality and just treat each object file independently. Besides resolving those relocations for ET_REL files, Dwfl also provides various (default/standard) callbacks to find/associate separate debuginfo to an Elf file. See Dwfl_Callbacks and the "Standard callbacks" in the libdwfl.h file. If you do use it, it might override/change some search paths for where to get the Dwarf data/file from. Again, you could not use this functionality if you don't like it. (Dwfl also works when you provide it the Dwarf data files directly.) Just look at what you need/want. Cheers, Mark
