MachineContext's instructionPointer() should handle null PCs correctly.
authormark.lam@apple.com <mark.lam@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Fri, 25 May 2018 23:45:36 +0000 (23:45 +0000)
committermark.lam@apple.com <mark.lam@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Fri, 25 May 2018 23:45:36 +0000 (23:45 +0000)
commita7396c9763629c00acab4c52bd43314275f6629f
tree43939dc6663052c45a2a2438032543cb01a41e81
parent49915bbd8dbe919f6c0b31d689643b86c6aa9293
MachineContext's instructionPointer() should handle null PCs correctly.
https://bugs.webkit.org/show_bug.cgi?id=186004
<rdar://problem/40570067>

Reviewed by Saam Barati.

instructionPointer() returns a MacroAssemblerCodePtr<CFunctionPtrTag>.  However,
MacroAssemblerCodePtr's constructor does not accept a null pointer value and will
assert accordingly with a debug ASSERT.  This is inconsequential for release
builds, but to avoid this assertion failure, we should check for a null PC and
return MacroAssemblerCodePtr<CFunctionPtrTag>(nullptr) instead (which uses the
MacroAssemblerCodePtr(std::nullptr_t) version of the constructor instead).

Alternatively, we can change all of MacroAssemblerCodePtr's constructors to check
for null pointers, but I rather not do that yet.  In general,
MacroAssemblerCodePtrs are constructed with non-null pointers, and I prefer to
leave it that way for now.

Note: this assertion failure only manifests when we have signal traps enabled,
and encounter a null pointer deref.

* runtime/MachineContext.h:
(JSC::MachineContext::instructionPointer):

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@232215 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Source/JavaScriptCore/ChangeLog
Source/JavaScriptCore/runtime/MachineContext.h