public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "jsm28 at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug libc/15868] New: backtrace interfaces and calls to noreturn functions Date: Tue, 20 Aug 2013 20:13:00 -0000 [thread overview] Message-ID: <bug-15868-131@http.sourceware.org/bugzilla/> (raw) http://sourceware.org/bugzilla/show_bug.cgi?id=15868 Bug ID: 15868 Summary: backtrace interfaces and calls to noreturn functions Product: glibc Version: 2.18 Status: NEW Severity: normal Priority: P2 Component: libc Assignee: unassigned at sourceware dot org Reporter: jsm28 at gcc dot gnu.org CC: drepper.fsp at gmail dot com Created attachment 7155 --> http://sourceware.org/bugzilla/attachment.cgi?id=7155&action=edit Testcase The backtrace / backtrace_symbols / backtrace_symbols_fd interfaces do not work well when backtracing through calls to noreturn functions (a natural use case - a noreturn error-handling function might reasonably wish to print a backtrace). This is illustrated by the attached testcase on x86_64. At least with some GCC versions, the call to a noreturn function has return address pointing to padding after the end of the calling function, meaning that it does not point inside that function and so a name for it cannot be found. The backtrace interface is that the addresses are return addresses. But reliable backtracing requires additional information about whether frames are signal frame, in which case the return address points inside the relevant function, or not, in which case you should subtract 1 to be sure of being inside the relevant function. (That involves calling _Unwind_GetIPInfo instead of _Unwind_GetIP to get the relevant information.) So to support this case reliably, there should be new interfaces that handle this adjustment in some way. (Old discussion started at: http://www.eglibc.org/archives/patches/msg01077.html .) -- You are receiving this mail because: You are on the CC list for the bug.
next reply other threads:[~2013-08-20 20:13 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-08-20 20:13 jsm28 at gcc dot gnu.org [this message] 2014-06-13 13:06 ` [Bug libc/15868] " fweimer at redhat 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-15868-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).