Bug 265218 – REGRESSION(270651@main): Broke cloop build: LowLevelInterpreter.asm:2778 in call to entry: Could not find macro entry (MacroError)

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Michael Catanzaro]

This is sort of a regression from 270651@main. When building for x86_64 with -DENABLE_JIT=OFF -DENABLE_C_LOOP=ON -DENABLE_SAMPLING_PROFILER=OFF we hit this error:

[266/494] Generating ../../JavaScriptCore/DerivedSources/LLIntDesiredOffsets.h
FAILED: JavaScriptCore/DerivedSources/LLIntDesiredOffsets.h /home/mcatanzaro/Projects/WebKit/WebKitBuild/JSCOnly/JavaScriptCore/DerivedSources/LLIntDesiredOffsets.h 
cd /home/mcatanzaro/Projects/WebKit/WebKitBuild/JSCOnly/Source/JavaScriptCore && /usr/bin/ruby /home/mcatanzaro/Projects/WebKit/Source/JavaScriptCore/offlineasm/generate_offset_extractor.rb -I/home/mcatanzaro/Projects/WebKit/WebKitBuild/JSCOnly/JavaScriptCore/DerivedSources/ /home/mcatanzaro/Projects/WebKit/Source/JavaScriptCore/llint/LowLevelInterpreter.asm /home/mcatanzaro/Projects/WebKit/WebKitBuild/JSCOnly/bin/LLIntSettingsExtractor /home/mcatanzaro/Projects/WebKit/WebKitBuild/JSCOnly/JavaScriptCore/DerivedSources/LLIntDesiredOffsets.h C_LOOP normal
LowLevelInterpreter.asm:2778 in call to entry: Could not find macro entry (MacroError)

Problem is here:

entry(wasm, macro()
    include InitWasm
end)

The entry macro is defined only when C_LOOP and C_LOOP_WIN are both disabled, but this new code in the WEBASSEMBLY condition uses it unconditionally. Should WebAssembly be disabled when C_LOOP is enabled, or is there another possible fix?

[Radar WebKit Bug Importer]

<rdar://problem/118899367>

[Michael Catanzaro]

Pull request: https://github.com/WebKit/WebKit/pull/21029

[EWS]

Committed 271252@main (49e6e8770b50): <https://commits.webkit.org/271252@main>

Reviewed commits have been landed. Closing PR #21029 and removing active labels.

[WebKit Commit Bot]

Re-opened since this is blocked by bug 265510

[Michael Catanzaro]

Hey Claudio, can you share what went wrong here please? I didn't notice any problems when I tested a clean build, but no doubt something is wrong in some configuration....

[Claudio Saavedra]

Some of the build errors:

1
2
/app/webkit/Source/JavaScriptCore/b3/B3WasmBoundsCheckValue.cpp: In constructor 'JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue(JSC::B3::Origin, JSC::B3::Value*, unsigned int, size_t)':
/app/webkit/Source/JavaScriptCore/b3/B3WasmBoundsCheckValue.cpp:53:103: error: 'fastMappedRedzoneBytes' is not a member of 'JSC::Wasm::Memory'

In file included from /app/webkit/WebKitBuild/GTK/Release/JavaScriptCore/DerivedSources/unified-sources/UnifiedSource-23a5fd0e-9.cpp:5:
/app/webkit/Source/JavaScriptCore/b3/B3Validate.cpp: In member function 'void JSC::B3::{anonymous}::Validater::run()':
/app/webkit/Source/JavaScriptCore/b3/B3Validate.cpp:457:58: error: 'simdScalarType' is not a member of 'JSC::Wasm'
/app/webkit/Source/JavaScriptCore/b3/B3Validate.cpp:457:43: error: 'toB3Type' was not declared in this scope
/app/webkit/Source/JavaScriptCore/b3/B3Validate.cpp:465:68: error: 'simdScalarType' is not a member of 'JSC::Wasm'
/app/webkit/Source/JavaScriptCore/b3/B3Validate.cpp:465:53: error: 'toB3Type' was not declared in this scope
/app/webkit/Source/JavaScriptCore/b3/B3Validate.cpp:487:68: error: 'simdScalarType' is not a member of 'JSC::Wasm'
/app/webkit/Source/JavaScriptCore/b3/B3Validate.cpp:487:53: error: 'toB3Type' was not declared in this scope


According to Carlos García this got defined:

#define ENABLE_WEBASSEMBLY 0

And that's causing the breakage.

[Michael Catanzaro]

I'm afraid I changed the default value of the ENABLE_WEBASSEMBLY setting to "NOT" when I wanted it to be "NOT ${ENABLE_C_LOOP_DEFAULT}". Don had warned me that it probably wouldn't work, but I improperly convinced myself that it was fine.

Safe merge queue would have caught this before it landed. Hopefully we can eventually make that work reliably....

[Michael Catanzaro]

Pull request: https://github.com/WebKit/WebKit/pull/21078

[Claudio Saavedra]

(In reply to Michael Catanzaro from comment #7)

> 
> Safe merge queue would have caught this before it landed. Hopefully we can
> eventually make that work reliably....

Maybe not, at least all linux build bots were green even with this patch, so maybe it would not have been caught. That made it tricky to find the culprit too.

[EWS]

Committed 271347@main (e2a9ebe5b7da): <https://commits.webkit.org/271347@main>

Reviewed commits have been landed. Closing PR #21078 and removing active labels.