Makes sense to me. -Filip
> On Feb 8, 2016, at 12:33 PM, Mark Lam <mark....@apple.com> wrote: > > 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
