Working with ELF already loaded in memory
Fri Jul 9 05:34:26 GMT 2021
> -----Original Message-----
> From: Mark Wielaard <email@example.com>
> Sent: Thursday, July 8, 2021 8:02 AM
> To: Sonal Santan <firstname.lastname@example.org>; email@example.com
> 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
> > 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?
> 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,
More information about the Elfutils-devel