* 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.
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