[webkit-dev] Change WTFCrash to not trash the crash site register state.

[Mark Lam]

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 <fpizlo at 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.lam at 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 at lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>