Hi Sinal, On Thu, 2021-07-08 at 05:02 +0000, Sonal Santan via Elfutils-devel wrote: > Going through the libdw it appears that all APIs require either a > file handle or a file name of the ELF object to create a session. > Since we do not have access to the ELF file -- but rather the ELF > file contents are already loaded in memory -- is there any other > mechanism to create a session for extracting DWARF information using > libdw?
Yes, if you just need the information already loaded into memory and you know where the library is mapped you can use: /* Create descriptor for memory region. */ extern Elf *elf_memory (char *__image, size_t __size); You can then use that Elf handle to extract the information that has been mapped in. Which often is not the actual debug information though. If you have a Elf handle you can use: /* Returns the build ID as found in a NT_GNU_BUILD_ID note from either a SHT_NOTE section or from a PT_NOTE segment if the ELF file doesn't contain any section headers. On success a pointer to the build ID is written to *BUILDID_P, and the positive length of the build ID is returned. Returns 0 if the ELF lacks a NT_GNU_BUILD_ID note. Returns -1 in case of malformed data or other errors. */ extern ssize_t dwelf_elf_gnu_build_id (Elf *elf, const void **build_idp); You can then use the build_id to lookup the debug information (file). You can also use libdwfl (part of libdw) to do some of the above automagically. See for example: /* Call dwfl_report_module for each file mapped into the address space of PID. Returns zero on success, -1 if dwfl_report_module failed, or an errno code if opening the proc files failed. */ extern int dwfl_linux_proc_report (Dwfl *dwfl, pid_t pid); The Dwfl will then be a representation of the modules (executable and shared libraries) of that particular process. You can then iterate through those modules using dwfl_getmodules and get a Dwarf handle using dwfl_module_getdwarf (or for all with dwfl_getdwarf). libdw will then try to extract that build-id from each module and try various lookups to get the (separate on disk) debuginfo. Hope that helps, Mark