Hi Serhei, On Thu, Mar 20, 2025 at 9:24 AM Serhei Makarov <ser...@serhei.io> wrote: > > On Wed, Mar 19, 2025, at 5:36 PM, Mark Wielaard wrote: > > > > On Sun, Mar 16, 2025 at 07:14:11PM -0400, Serhei Makarov wrote: > >> Since libebl is a private interface, subsequent patches in the series > >> introduce another api wrapping the libebl perf register handling. In > >> this patch, add an interface to access the preferred set of registers > >> that libdwfl would like to see to allow proper unwinding of stack > >> sample data. > >> > >> * libdwfl/libdwfl.h (dwfl_perf_sample_preferred_regs_mask): > >> New function. > >> * libdwfl/dwfl_perf_frame.c: New file. > >> (dwfl_perf_sample_preferred_regs_mask): New function. > >> * libdw/libdw.map: Add dwfl_perf_sample_preferred_regs_mask. > >> * libdwfl/Makefile.am: Add dwfl_perf_frame.c. > > > > I probably need to read the rest of the patch series first. On its own > > I am not a fan, it feels very much an implementation detail that > > should be abstracted away. > > Yeah, the trouble is that it's an implementation detail that needs to be > agreed on between elfutils (which does unwinding) and the profiler (which > calls perf_event_open and provides regs_mask). So there are two ways to do > that. Either the profiler decides which regs_mask to use, or the profiler > asks elfutils for a regs_mask. The function in this patch is meant to support > the latter scenario, which gives the profiler confidence that it's picking a > set of registers elfutils can work with.
Elfutils and the profiler will need to coordinate these details, but I still have reservations about exposing perf-specific constructs (regs_mask, abi) in the stable libdwfl API when these constructs don't generalize well to all samplers we may want to support in the future. Ideally libdwfl offers a single, generic interface capable of supporting any sample type. That interface will have to accommodate sampler-specific details like perf's reg_mask and abi, but I'd prefer if we avoid adding non-generic per-sampler public functions to libdwfl. I know we're close to the next release and I do want this work to be included. My proposal is to move the current API out of libdwfl and into a new library, as-is but clearly marked as experimental and subject to possible API/ABI breakage. This fits with the "experimental" label that eu-stacktrace still carries. The new functionality introduced in this series makes it into the release and we retain flexibility to iterate on the design without affecting libdwfl itself. Aaron
