Fix for #178. dwfl_attach_state should be called only for user-level …

[vtoropov]

Fix for #178. The function dwfl_attach_state should be called only for user-level CPU register state
and user level stack, allowing stack unwinding

[milianw]

thanks, but some more work is needed on this

[milianw]

please copy the full definition from an up2date perf_event.h

[milianw]

actually, please use PerfEventAttributes::SampleFormat instead

[vtoropov]

Good, the using PerfEventAttributes::SampleFormat instead enum perf_event_sample_format is ok.
I think that the enum from perf_event.h is redundant in this case

[milianw]

this part shouldn't be checked here, it will break analysis of data files recorded without --call-graph dwarf - we still want dwfl setup then to analyze inline frames and symbols

[milianw]

if this part is needed, then maybe move it to PerfUnwind::analyze - but I don't think we should need it - do we really get a userStack().length() > 0 without PERF_SAMPLE_STACK_USER? I doubt that

[vtoropov]

This check did not break analysis of data files recorded without --call-graph dwarf.
We simply disable the erroneous call to the dwfl_attach_state function. And this check should be done right here, after the if statement if (static_cast <pid_t> (m_pid) == dwfl_pid (m_dwfl)). In this case, the check does not violate the analysis in the resolveCallchain function, and moreover, unwindStack. Moreover, this check is performed only once for each pid when attachDwfl is called from unwindStack and only unnecessary calls from resolveCallchain are intercepted by this check.

[vtoropov]

I just looked at the checks when calling the dwfl_attach_state function in linux perf.
Perf report does the same check: machine.c, line 2495 -
if (! ((evsel-> core.attr.sample_type & PERF_SAMPLE_REGS_USER) &&
(evsel-> core.attr.sample_type & PERF_SAMPLE_STACK_USER)))
return 0;

[milianw]

cleaned up and expanded the commit message with a better explanation in 71689f1

thanks!