Hi Serhei,
On Wed, Aug 20, 2025 at 6:12 PM Serhei Makarov <ser...@serhei.io> wrote:
>
> Hello,
>
> I've been concerned to get libdwfl_stacktrace out of the weird 'experimental'
> limbo we put it in for the last elfutils release. To do that, we need to
> stabilize the API.
>
> My full prototype of a more mature API is delayed for reasons beyond my
> control, but sometime in September is the likely ETA. For now I want to get
> people's opinions (mjw? amerey?) on the most crucial change. To avoid
> depending on the Linux kernel specific perf_events API, we need a
> dwflst_sample_getframes() function that doesn't take perf_events formatted
> data.
>
> The header-only patch below illustrates the planned API change.
> The base solution is for dwflst_sample_getframes() to take a pointer to
> regs_mapping, which, for each item in regs[] array, specifies its position in
> the full register file expected by the DWARF functionality. (This avoids the
> need to take a perf_events regs bitmap that can only be interpreted with the
> aid of a weird enum header buried in the linux kernel tree.)
>
> The regs_mapping array is most likely to stay constant for an entire
> profiling session, so this is not a high-overhead interface.
>
> (A bit controversially, I'm allowing n_regs_mapping != n_regs, which might
> smoothly deal with cases where dwflst_sample_getframes is passed a profiling
> data packet with malformed or truncated regs array.)
>
> We *keep* the existing dwflst_perf_sample_getframes as a convenience variant
> of dwflst_sample_getframes. It clearly says 'perf', and I think it's fine to
> have this perf-specific API as long as it's not the *only* API.
I would still be concerned about needing
dwflst_perf_sample_getframes_v2, _v3, etc. if the perf sample format
or dwflst needs change in ways that would require API/ABI changes.
The same concern also applies to the generic dwflst_sample_getframes
if we decide to support a sample type that needs a different set of
parameters.
Instead of specifying the sample parameters as arguments to
dwflst_sample_getframes, what do you think about adding an API for
setting key/value pairs for the Dwflst_Process_Tracker (or related
object)? Then we can always add more key/value pairs without API/ABI
consequences. Something like the following:
dwflst_set_tracker_attr (Dwflst_Process_tracker *tracker,
dwflst_attr_type type, void *value);
where dwflst_attr_type is an enum of every parameter dwflst might need
and we can easily add more types over time. This would eliminate the
need for dwflst_perf_sample_getframes and dwflst_sample_getframes can
adapt to any future changes we might want to make.
Aaron
