From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9815 invoked by alias); 28 Aug 2014 08:08:16 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 9728 invoked by uid 48); 28 Aug 2014 08:07:52 -0000 From: "m.ilin at samsung dot com" To: glibc-bugs@sourceware.org Subject: [Bug build/17324] New: ld -r not generate cantunwind records in .ARM.exidx section Date: Thu, 28 Aug 2014 08:08:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: build X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: m.ilin at samsung dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-08/txt/msg00119.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=17324 Bug ID: 17324 Summary: ld -r not generate cantunwind records in .ARM.exidx section Product: glibc Version: unspecified Status: NEW Severity: normal Priority: P2 Component: build Assignee: unassigned at sourceware dot org Reporter: m.ilin at samsung dot com CC: carlos at redhat dot com Created attachment 7764 --> https://sourceware.org/bugzilla/attachment.cgi?id=7764&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.