[PATCH] s390: Remove backchain-based fallback from backtrace

Stefan Liebler stli@linux.ibm.com
Wed Feb 12 08:51:00 GMT 2020


On 2/11/20 4:44 PM, Florian Weimer wrote:
> * Stefan Liebler:
> 
>> Hi Florian,
>>
>> is there a background story behind this patch or do you just want to
>> consolidate the s390-32/s390-64 implementation?
> 
> I'm working to consolidate the dynamic linking of the unwinder for the
> backtrace function and for pthread_cancel/pthread_exit.  That's how I
> encountered the issue.
> 
>> On 2/10/20 7:04 PM, Florian Weimer wrote:
...
>> That means, if somebody has no libgcc and has not build with
>> -mbackchain, then __backchain_backtrace will try to walk anywhere and
>> we could get segfaults as it seems the sanity checks (backchain-slot
>> == NULL or backchain-slot > __libc_stack_end) are not sufficient!?
>>
>> This also means, if somebody has build with backchain and has libgcc
>> installed, then always _Unwind_Backtrace is called.
>> If the binary was build with gcc -fno-asynchronous-unwind-tables, then
>> there is no retry with __backchain_backtrace and there won't be a
>> backtrace.
>> If the binary contains the unwind-tables, then those are used and not
>> the backchain.
> 
> That sounds like a problem, but it's not the one I originally expected.
> 
> I still think the code change in my patch is valid because pretty much
> all systems will have libgcc_s installed (it's required for C++, after
> all), and thus the backchain processing is essentially dead.  It's only
> used of dlopen fails (e.g., due to lack of file descriptors).  But
> that's not useful because the fallback implements something completely
> different.
> 
Please wait before removing it at all. We'll discuss this internally if 
removing / moving to libgcc_s is okay for us and try to figure out if 
the customer in mind is having a libgcc_s or not.

Bye,
Stefan
 >
...
>> Should __backchain_backtrace have more checks regarding addresses in
>> backchain-slot and/or the assumed function-address?
> 
> I think this has to be part of the libgcc_s unwinder because in many
> environments, the system libraries have DWARF unwinding data, but other
> objects may not have them and could use the backchain.  Then the
> question becomes how to mark frames as using the backchain-based
> unwinder.
> 
> Thanks,
> Florian
> 



More information about the Libc-alpha mailing list