Created attachment 7763 [details]
The issue is ARM specific.
We've investigated a segfautl that happend when libgcc unwinder executes
unwinding bytecode. During backtrace the unwinder may looking for the entry
of a function that actually not presented in .ARM.exidx of libc.so. The
function has no even cantunwind stub. And this seems strange.
Unwinider search function (search_EIT_table) returns the nearest valid entry
according to specified address. Then the unwinder executes bytecode that belongs
to wrong function and continues unwinding. The next steps bring more frames that
are not already valid in the context. Depends on the stack layout this can lead
to a segfault.
We attach a small demo that demostrates how a binary file can lose cantunwind
table entries (the same happend with GLibc). The demo builds 2 shared objects:
the first one has all entries, the second loses one entry. libc.so is built the
same way as the second file. All binaries are packed into an archive with ar
utility then the archive is relocated (ld -r). Just after THIS stage the binary
file loses cantunwind entries. Finally the relocatable file is converted into a
shared object which certainly won't have these entries either.
The point is that binutils ld adds cantunwind records for binaries without
unwinding sections. But it doesnt when ld called with -r option so cantunwind
records are not created.
The issue is reporoduced with GLibc that was built with the toolchain where
-funwind-tables or -fasynchronous-unwind-tables options are DISABLED by default.
So it means that compiled binaries won't have additional information for
the unwinder. But this is not fully true for GLibc, actually libc-2.18.so
has NON-EMPTY section .ARM.exidx with info to the unwider. In building
scripts some files have to be built with option -fasynchronous-unwind-tables
that forces generation of unwind tables (GLibc NPTL needs the option being
enabled for thread cancellation). So the unwind table has entry only for these
functions. During linking stage object files that were built without unwind
tables come to the final binary without cantunwind records is .ARM.exidx.
Added ARM maintainers.
*** Bug 17324 has been marked as a duplicate of this bug. ***
Created attachment 7792 [details]
Please try out this patch and let me know if it works for you.
We did the same patching before but this it not enough. After the suggested change a relocatable file itself looks good. But when we try to create a shared object from this relocatable the result unwind table will be incorrect. It is occurred because added unwind entry also needs R_ARM_PREL31 relocation record. But it is not provided by ld -r.
Having time we've been returning to the issue and trying to find a right callback or a macro defined action in ARM bfd backend where we can add the relocation record. If you know the appropriate place please share your ideas with us.
Created attachment 8859 [details]
New patch created and sent for rewiew:
Correct relocation for new cantunwind entry is generated.
Patch committed https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=491d01d3da18fb61fa6c7c61c091b4cb8c5773f7