[Bug ld/17323] New: ld -r not generate cantunwind records in .ARM.exidx section

[m.ilin at samsung dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17323

            Bug ID: 17323
           Summary: ld -r not generate cantunwind records in .ARM.exidx
                    section
           Product: binutils
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ld
          Assignee: unassigned at sourceware dot org
          Reporter: m.ilin at samsung dot com

Created attachment 7763
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7763&action=edit
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

-- 
You are receiving this mail because:
You are on the CC list for the bug.