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

[Claudiu Zissulescu-Ianculescu]

On 4/22/25 3:32 PM, Jens Remus wrote:
> On 22.04.2025 10:55, Claudiu Zissulescu-Ianculescu wrote:
>> On 4/18/25 6:09 PM, Florian Weimer wrote:
>>> * claudiu zissulescu-ianculescu:
>>>
>>>> +/* Initialize the SFrame backtrace routine, and try to backtrace the
>>>> +   current stack using SFrame info.  The return value of SFrame stack
>>>> +   tracer must be larger than one to consider the SFrame backtrace
>>>> +   valid. Otherwise, there may be the case that glibc is compiled
>>>> +   using SFrame but the application not.   */
>>>> +
>>>> +#define DO_SFRAME_BACKTRACE(ARRAY, SIZE)            \
>>>> +  do                                \
>>>> +    {                                \
>>>> +      int cnt;                            \
>>>> +      frame frame;                        \
>>>> +      frame.pc = getPC();                    \
>>>> +      frame.sp = getSP();                    \
>>>> +      frame.fp = (_Unwind_Ptr) __builtin_frame_address (0);    \
>>>> +      cnt = stacktrace_sframe (ARRAY, SIZE, &frame);        \
>>>> +      if (cnt > 1)                        \
>>>> +    return cnt;                        \
>>>> +    }                                \
>>>> +  while(0)
>>>
>>> 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.
>>
>> The above macro should avoid truncating the backtrace when sframe
>> information is not present, or only present in glibc library.
>> When SFrame info is not present in the last frame, then the
>> stacktarce_sframe returns 0, thus rolling back to DWARF unwinding.
>> When SFrame info is only present in the last frame (i.e., glibc
>> backtrace) but not in the backtrace caller, then stacktrace_sframe
>> should return 1, thus forcing again the DWARF unwinding procedure to
>> kick in.
> 
> Maybe it would be good to force a fallback to the DWARF backtracer,
> if an object without SFrame information is met.  Except form the
> initial patch:
> 

Of course the solution is in front of our eyes .... This may work ...
what do you think Florian?

Best wishes,
Claudiu