Hello Mark, > -----Original Message----- > From: Mark Wielaard <m...@klomp.org> > Sent: Thursday, July 8, 2021 8:02 AM > To: Sonal Santan <son...@xilinx.com>; elfutils-devel@sourceware.org > Subject: Re: Working with ELF already loaded in memory > > 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. >
Thanks for the pointer. I was looking for APIs inside /usr/include/elfutils directory and did not realize elfutils also places header files under /usr/include directory. I am working with this API now. > 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); Does this also work for ELF files which are loaded into heap as blob -- not really _mapped_ into the address space? I guess I will have to provide some hints to dwfl so it can locate the loaded blob when walking through the process map? Thanks, -Sonal > > 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
