1765359 - Browser builds with `--enable-record-tuple` fails to compile WasmSignalHandlers.cpp

Status: RESOLVED FIXED

(Core :: JavaScript: WebAssembly, defect, P3)

Description

[Matthew Gaudet (he/him) [:mgaudet]]

On my laptop (M1 MBP) My builds fail if I add --enable-record-tuple to my mozconfig:

4:47.86 layout/base
 4:48.89 In file included from Unified_cpp_js_src_wasm4.cpp:29:
 4:48.89 /Users/mgaudet/unified/js/src/wasm/WasmSignalHandlers.cpp:904:30: error: use of undeclared identifier 'sMachDebugPort'
 4:48.89                             &sMachDebugPort);
 4:48.89                              ^
 4:48.92 /Users/mgaudet/unified/js/src/wasm/WasmSignalHandlers.cpp:908:51: error: use of undeclared identifier 'sMachDebugPort'
 4:48.92   kret = mach_port_insert_right(mach_task_self(), sMachDebugPort,
 4:48.92                                                   ^
 4:48.92 /Users/mgaudet/unified/js/src/wasm/WasmSignalHandlers.cpp:909:33: error: use of undeclared identifier 'sMachDebugPort'
 4:48.92                                 sMachDebugPort, MACH_MSG_TYPE_MAKE_SEND);
 4:48.92                                 ^
 4:48.93 /Users/mgaudet/unified/js/src/wasm/WasmSignalHandlers.cpp:918:27: error: use of undeclared identifier 'MachExceptionHandlerThread'
 4:48.93   if (!handlerThread.init(MachExceptionHandlerThread)) {
 4:48.93                           ^
 4:48.93 /Users/mgaudet/unified/js/src/wasm/WasmSignalHandlers.cpp:956:22: error: use of undeclared identifier 'sMachDebugPort'
 4:48.93   MOZ_RELEASE_ASSERT(sMachDebugPort != MACH_PORT_NULL);
 4:48.93                      ^
 4:48.94 /Users/mgaudet/unified/js/src/wasm/WasmSignalHandlers.cpp:956:22: error: use of undeclared identifier 'sMachDebugPort'
 4:48.96 /Users/mgaudet/unified/js/src/wasm/WasmSignalHandlers.cpp:960:7: error: use of undeclared identifier 'sMachDebugPort'
 4:48.96       sMachDebugPort, EXCEPTION_DEFAULT | MACH_EXCEPTION_CODES,
 4:48.96       ^
 4:49.06 BUILDSTATUS BUILD_VERBOSE js/src

Not sure what is going on here -- I haven't yet verfied if this is also happening on Linux.

Comment 1

[Matthew Gaudet (he/him) [:mgaudet]]

Hey Tim,

Just in case you've got an idea for whats up here...

Comment 2

[Lars T Hansen [:lth]]

This should also be happening on x64 Darwin but I haven't tested yet.

The problem is that --enable-record-tuple disables the JIT so we get JS_CODEGEN_NONE, and this means eg MachExceptionHandlerThread is not defined because it's under the appropriate ifdef. But later in that file there is code under #ifdef XP_DARWIN that just assumes that we have a JIT without testing the ifdef (really all of Wasm assumes we have a JIT), and this will now fail. I think the fix here is to update the ifdeffery in wasm.

Comment 3

[Lars T Hansen [:lth]]

Attachment: Bug 1765359 - Fix ifdeffery in Wasm signal handling. r?yury

The problem here is that we assumed incorrectly that XP_DARWIN => some JIT. The
proper solution is to make the signal handling interface inert in the face of nojit.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

Comment 5

[Lars T Hansen [:lth]]

Sigh.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f96e3ef2864b
Fix ifdeffery in Wasm signal handling. r=yury

Comment 7

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/f96e3ef2864b