On Thu, Apr 3, 2025, at 1:19 PM, Serhei Makarov wrote:
> On Sun, Mar 16, 2025, at 7:15 PM, Serhei Makarov wrote:
>> +/* The same callback, except this first attempts to look up a cached
>> + Elf* and fd from the Dwfl_Module's Dwfl_Process_Tracker (if any).
>> + If a new Elf* has to be created, this saves it to the cache. */
>> +extern int dwfl_process_tracker_find_elf (Dwfl_Module *mod, void **userdata,
>> + const char *module_name, Dwarf_Addr base,
>> + char **file_name, Elf **);
> In the reworked patchset I'm trying to expand this api a bit
> to allow other find_elf callbacks to be used with caching.
>
> I'm thinking to introduce a pair of functions for more direct cache access:
>
> bool dwfl_process_tracker_find_cached_elf (tracker, module_name,
> file_name, elfp, &fd);
> bool dwfl_process_tracker_cache_elf (tracker, module_name, file_name,
> elf, fd);
>
> ...
>
> Might come up with a better idea after thinking a bit more today, but
> this is the best I have so far.
Considering this again; going to implement these functions
(since they make the code significantly cleaner) but
avoid making them public for now. Looking at the code where they
might be useful in Sysprof, I notice that for containerized code
they load "/proc/%pid/root/%modulename", which is not a key
that's useful for caching across different pids. Using just %modulename
(the path) is also dangerous due to it referring to different instances of a
module
across different containers or the system root. So either the API needs to
support
some other key for caching, or it can't be applied here. The problem here
is not being able to tell from the /proc/%pid path which %pids
belong to the same container, let alone when the same container
image is multiply instantiated.
