mikeash.com pyblog/friday-qa-2012-04-27-plcrashreporter-and-unwinding-the-stack-with-dwarf.html commentshttp://www.mikeash.com/?page=pyblog/friday-qa-2012-04-27-plcrashreporter-and-unwinding-the-stack-with-dwarf.html#commentsmikeash.com Recent CommentsFri, 29 Mar 2024 06:21:44 GMTPyRSS2Gen-1.0.0http://blogs.law.harvard.edu/tech/rssMark Aufflick - 2012-05-01 03:55:58http://www.mikeash.com/?page=pyblog/friday-qa-2012-04-27-plcrashreporter-and-unwinding-the-stack-with-dwarf.html#commentsWow this is exciting. None of my Mac apps ship via the app store not yet, but not having crash reporting has made me dread the app store. Not for much longer though - good work Gwynne and the always awesome HockeyApp guys!8272ca22175e793d9b51c3b03325c824Tue, 01 May 2012 03:55:58 GMTLandon Fuller - 2012-04-27 19:57:43http://www.mikeash.com/?page=pyblog/friday-qa-2012-04-27-plcrashreporter-and-unwinding-the-stack-with-dwarf.html#commentsUnfortunately upstream libunwind doesn't support Darwin, Mach-O, or the compact unwind encoding. <br /> <br />Apple has their own open-source implementation of a small subset of libunwind, but it's licensed under the APSL, and the version shipped with Mac OS X can't be used for our purposes without relying on private API and/or undefined semantics. Given the redistribution requirements around the APSL that could affect library users themselves, shipping our own customized version of Apple's minimal libunwind wasn't deemed workable. <br /> <br />Gwynne's work ultimately provides a standalone async-safe, C-based, MIT-licensed frame walking implementation.263e4767722a5b44b021b2a9d4284d86Fri, 27 Apr 2012 19:57:43 GMTJoe Groff - 2012-04-27 19:06:29http://www.mikeash.com/?page=pyblog/friday-qa-2012-04-27-plcrashreporter-and-unwinding-the-stack-with-dwarf.html#commentsGood points, Landon. How about libunwind then? <a href="http://www.nongnu.org/libunwind/">http://www.nongnu.org/libunwind/</a>fff77e493954a3dc23d2e26c14623865Fri, 27 Apr 2012 19:06:29 GMTLandon Fuller - 2012-04-27 16:15:39http://www.mikeash.com/?page=pyblog/friday-qa-2012-04-27-plcrashreporter-and-unwinding-the-stack-with-dwarf.html#commentsHey Joe -- <br /> <br />Unfortunately neither of those are async-safe, can only be used on the current thread, and can hide information that is necessary in a crash reporter. I've written a bit more about the issues involved in crash reporting here: <br /> <br /><a href="http://landonf.bikemonkey.org/code/objc/Reliable_Crash_Reporting.20110912.html">http://landonf.bikemonkey.org/code/objc/Reliable_Crash_Reporting.20110912.html</a>fdbda5c522a9e36a471770b17281a1a8Fri, 27 Apr 2012 16:15:39 GMTLandon Fuller - 2012-04-27 16:13:30http://www.mikeash.com/?page=pyblog/friday-qa-2012-04-27-plcrashreporter-and-unwinding-the-stack-with-dwarf.html#commentsHi Chris -- <br /> <br />There can be a measurable performance gain when making the extra register available, assuming that the compiler's heuristics for doing so aren't broken, and you're spending more time executing code that benefits from the register than you spend stack walking (usually a safe bet?). <br /> <br />If I recall correctly, certain GCC versions would *prefer* the callee-saved frame pointer over other callee-stompable registers when -fomit-frame-pointer was specified on x86. This lead to *less* efficient code, since it would have been more efficient to use a register that didn't require callee-preservation. <br /> <br />On x86-64, the ABI explicitly specifies that -fomit-frame-pointer semantics are the default, so it couldn't be relied on for crash reporting even if we wanted to.3d6a72514a0a80d0555b21be09df0352Fri, 27 Apr 2012 16:13:30 GMTJoe Groff - 2012-04-27 16:11:58http://www.mikeash.com/?page=pyblog/friday-qa-2012-04-27-plcrashreporter-and-unwinding-the-stack-with-dwarf.html#commentsYou can use the libc functions backtrack, backtrace_symbols, and backtrace_symbols_fd to get this same information.16f78712cc6c48d6c279c01d88172ff8Fri, 27 Apr 2012 16:11:58 GMTFarcaller - 2012-04-27 14:43:45http://www.mikeash.com/?page=pyblog/friday-qa-2012-04-27-plcrashreporter-and-unwinding-the-stack-with-dwarf.html#commentsIt would be nice to see the same in corellation to arm binaries.d993957aa4db950656f125191488d29fFri, 27 Apr 2012 14:43:45 GMTChris - 2012-04-27 14:40:37http://www.mikeash.com/?page=pyblog/friday-qa-2012-04-27-plcrashreporter-and-unwinding-the-stack-with-dwarf.html#commentsWouldn't building with stack frame pointers be a lot easier? Is there a measurable performance reason why they're omitted in release builds?493b9e9d299da06b75d912759981381bFri, 27 Apr 2012 14:40:37 GMT