[PATCH v4 2/5] elf: Add SFrame stack tracing

[Claudiu Zissulescu-Ianculescu]

>>> Shouldn't this switch to DWARF backtracing to avoid a truncated
>>> backtrace?  Otherwise std::stacktrace::current() will not work anymore
>>> once glibc and libstdc++ are upgraded, I think.
>>
>> If the returned count is equal or less than 1 (accounting for backtrace
>> itself), then the logic falls back to DWARF backtracing.  If the count
>> is greater than 1, the assumption is that SFrame backtracing is complete.
>> I am not sure whether it would be possible to distinguish whether SFrame
>> backtracing reached a terminal frame (e.g. _start) or failed to fallback
>> to DWARF backtracing in the latter case.
> 
> I think this is really something that needs to be solved.  Maybe not for
> std::stacktrace (because it uses libbacktrace and thus ignores SFrame
> for now), but there will be similar libraries that we wouldn't be able
> to build with SFrame support without hiding all backtraces because of
> the truncated SFrame-based trace.
> 
I see what is your concern here, you may be worried that the sframe
stack tracer will stop before the point which may be achieved using
DWARF, and you propose to continue with DWARF from that point on (or
something of a sort). My concern here is that the DWARF unwinder may not
be so easily setup to start from any given stack frame. Moreover, the
dwarf unwinder is part of libgcc, thus complicating the "resume/start
from here" dwarf unwinder functionality.

I'll try to see what I can come with on this topic. Thank you,
Claudiu