A store to 0xbbadbeef will still require the use of a register (at least on ARM). The breakpoint instruction uses no registers (hence, we don’t have to choose which register to sacrifice). We can still identify the crash as an assertion by looking fro the EXC_BREAKPOINT instead of the 0xbbadbeef address.
Mark > On Feb 8, 2016, at 12:14 PM, Filip Pizlo <fpi...@apple.com> wrote: > > I like this idea. I’ve wanted this for a while. > > Can you explain why your approach doesn’t inline a store to 0xbbadbeef, so > that this aspect of the current behavior is preserved? > > -Filip > > >> On Feb 8, 2016, at 11:55 AM, Mark Lam <mark....@apple.com> wrote: >> >> Hi WebKit folks, >> >> For non-debug OS(DARWIN) builds, I would like to change WTFCrash()’s >> implementation into an inlined function that has a single inlined asm >> statement that issues a breakpoint trap. The intent is to crash directly in >> the caller’s frame and preserve the register values at the time of the >> crash. As a result, for non-debug OS(DARWIN) builds, crashes due to failed >> RELEASE_ASSERTs will now show up in crash reports as crashing due to >> EXC_BREAKPOINT (SIGTRAP) instead of a EXC_BAD_ACCESS (SIGSEGV) on address >> 0xbbadbeef. >> >> This is in contrast to the current implementation where WTFCrash() is a >> function that calls a lot of handler / callback functions before actually >> crashing. As a result, by the time it crashes, the caller’s register values >> has most likely been trashed by all the work that the WTFCrash and the >> handlers / callbacks do. The register values in the captured crash report >> will, therefore, no longer be useful for crash site analysis. >> >> You can find the patch for this change at >> https://bugs.webkit.org/show_bug.cgi?id=153996. This change will only be >> applied for non-debug OS(DARWIN) builds for now. I’m leaving all other >> build build configurations with the existing WTFCrash() implementation and >> behavior. >> >> Does anyone have any opinion / feedback on this change? >> >> Thanks. >> >> Regards, >> Mark >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> https://lists.webkit.org/mailman/listinfo/webkit-dev > _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
