public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "m.ilin at samsung dot com" <sourceware-bugzilla@sourceware.org> 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 [thread overview] Message-ID: <bug-17324-131@http.sourceware.org/bugzilla/> (raw) 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.
next reply other threads:[~2014-08-28 8:08 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-08-28 8:08 m.ilin at samsung dot com [this message] 2014-08-28 17:05 ` [Bug build/17324] " joseph at codesourcery dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-17324-131@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).