Bug 17324 - ld -r not generate cantunwind records in .ARM.exidx section
Summary: ld -r not generate cantunwind records in .ARM.exidx section
Status: RESOLVED DUPLICATE of bug 17323
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-28 08:07 UTC by Mikhail
Modified: 2014-09-10 12:35 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments
demo (3.02 KB, application/x-compressed-tar)
2014-08-28 08:07 UTC, Mikhail
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mikhail 2014-08-28 08:07:47 UTC
Created attachment 7764 [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 joseph@codesourcery.com 2014-08-28 17:05:02 UTC
This sounds like it should be filed as a bug in the binutils product, not 
glibc.
Comment 2 Florian Weimer 2014-09-10 12:28:47 UTC
Reassining to binutils.
Comment 3 Andreas Schwab 2014-09-10 12:35:35 UTC
.

*** This bug has been marked as a duplicate of bug 17323 ***