Created attachment 79643 [details] Patch Added support for the situation when client program loads and executes ELF without associated ELF file. This patch detects such situation, and loads the debug info from the ELF memory object. I tested with helgrind and callgrind tools. Patch is against 3.8.0 release.
I am not familiar with ELF objects purely in memory. Where/When is "executing ELF without associated ELF file" needed/used? Is this FreeBSD specific?
No, this isn't specific to FreeBSD, and isn't used as often. But this is one way to run an ELF in a light-way fashion. Usually ELF is placed into the shared library and then dlopen-ed. dlopen mmaps the file and performs relocation. But the client process can choose to copy it into the mmapped area and perform relocation itself. This avoids creation of unnecessary files and makes it generally faster to start. Usually ET_REL ELF type is used like this. From the valgrind perspective, currently only mmap of ELF file triggers reading of debug info for this object. My patch enables vagrind to detect the situation when such code is running and load debug info for IP addresses that run de-facto . In other words, this is the situation when debug info has to be loaded after the point of mmap.
I believe, LLVM JIT does exactly such ELF injection to run an LLVM module. Creating the shared module file and loading it is obviously an unnecessary overhead.
Created attachment 80317 [details] Same patch against 3.8.1 Patch update for 3.8.1
This is old so I'm closing it. Perhaps I'll look at the patch one day just in case.
On second thoughts, this is not FreeBSD-specific. Patch for 3.8.1 though. This could be of use for macOS post Big Sur which has invisible system libs.