Bug 17323 - ld -r not generate cantunwind records in .ARM.exidx section
Summary: ld -r not generate cantunwind records in .ARM.exidx section
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.25
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 17324 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-08-28 08:05 UTC by Mikhail
Modified: 2015-12-23 11:43 UTC (History)
5 users (show)

See Also:
Host:
Target: arm
Build:
Last reconfirmed:


Attachments
demo (3.02 KB, application/x-compressed-tar)
2014-08-28 08:05 UTC, Mikhail
Details
Proposed patch (361 bytes, patch)
2014-09-17 12:59 UTC, Nick Clifton
Details | Diff
Proposed patch (4.11 KB, patch)
2015-12-21 13:58 UTC, Yury Usishchev
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mikhail 2014-08-28 08:05:31 UTC
Created attachment 7763 [details]
demo

Hi all

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.


-- Mikhail
Comment 1 Yury Gribov 2014-08-28 13:08:56 UTC
Added ARM maintainers.
Comment 2 Andreas Schwab 2014-09-10 12:35:35 UTC
*** Bug 17324 has been marked as a duplicate of this bug. ***
Comment 3 Nick Clifton 2014-09-17 12:59:46 UTC
Created attachment 7792 [details]
Proposed patch

Hi Mikhail,

  Please try out this patch and let me know if it works for you.

Cheers
  Nick
Comment 4 Mikhail 2014-09-17 13:27:45 UTC
Hi, Nick

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.

Thanks.

-- Mikhail
Comment 5 Yury Usishchev 2015-12-21 13:58:01 UTC
Created attachment 8859 [details]
Proposed patch

New patch created and sent for rewiew:
https://sourceware.org/ml/binutils/2015-12/msg00333.html

Correct relocation for new cantunwind entry is generated.