On Thu, Mar 20, 2025, at 8:01 AM, Mark Wielaard wrote:
> Hi Serhei,
>
> On Sun, 2025-03-16 at 19:14 -0400, Serhei Makarov wrote:
> I am wondering whether this isn't too abstract. libdwfl Dwfl's are
> already super abstract so they can be used for running processes and
> core dump and an offline or running kernel. Which is super powerful,
> but also slightly confusing at times.
>
> Can a Dwfl_Process_Tracker really take any callbacks and any Dwfl? Or
> would it make sense to limit it (as its name already implies) to Dwfls
> that report through dwfl_linux_proc_report with a given pid?
It's important to note that Dwfl_Process_Tracker collects multiple Dwfls that
report about processes with different pid's, for the system-wide profiling use
case.
That gives a way for these Dwfls to share an Elf data cache,
and query whether a Dwfl for a given pid has already been created.
It looks like I should adjust the comments to make that immediately obvious.
That's ok; for anything in the public headers, a lot of bikeshedding
is appropriate.
I don't see why it's necessarily tied to dwfl_linux_proc_report.
Any method of providing information about a live process would
work, including the profiler doing something custom with
the lower-level dwfl_report_... public functions. That might be
one way for sysprof to handle containers, for example,
without requiring us to reimplement their functionality
for peeking into container filesystems.
{One potentially confusing point about this api IMO comes later
in the patch series, where dwfl_perf_sample_getframes calls
dwfl_attach_state() if the Dwfl is unattached. I'm open to handling
it slightly differently, perhaps by splitting out the attach operation
into a separate function the profiler would need to call first.
I'll reiterate this in the discussion on patch12.}
