Bug 100364 – LLInt C_Loop build is broken

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: JavaScriptCore

[Simon Hausmann]

The build with the C_LOOP back-end is broken in two ways:

The error is:

generated/LLIntAssembly.h: In static member function 'static JSC::JSValue JSC::LLInt::CLoop::execute(JSC::CallFrame*, JSC::OpcodeID, bool)':
generated/LLIntAssembly.h:3731:14: error: label 'llint_op_resolve' used but not defined
generated/LLIntAssembly.h:3917:10: error: label 'llint_op_resolve_base' used but not defined

These errors come from the following two snippets in LowLevelInterpreter.asm:


_llint_op_resolve_base_to_global_dynamic:
    jmp _llint_op_resolve_base

and as part of _llint_op_resolve_global_property:

    bpneq JSCell::m_structure[t1], t2, _llint_op_resolve

In both cases the destination label is referred to in the same way as it is defined. When creating the destination
labels, offlineasm/asm.rb uses OFFLINE_ASM_OPCODE_LABEL for both because their name contains with llint_op_. However
labels passed to _OPCODE_LABEL() have the _llint_ prefix stripped, so the resulting label in LLIntAssembly.h is actually
op_resolve_base and op_resolve. Therefore the "jmp _llint_op_resolve_base" and the bpneq cannot find their targets.

The second error is that even if LowLevelInterpreter.asm used _op_resolve_base as target if C_LOOP, turning the jmp into
a "goto op_resolve_base;", the build breaks when computed gotos are not available, because the OFFLINE_ASM_OPCODE_LABEL
only defines a "case Foo:" target instead of a combined target that can also be used with goto, like GLUE_LABEL does it:

    case label: label:


A possible workaround for both issues seems to be to use an extra local label:


--- a/Source/JavaScriptCore/llint/LowLevelInterpreter.asm
+++ b/Source/JavaScriptCore/llint/LowLevelInterpreter.asm
@@ -662,7 +662,7 @@ _llint_op_resolve_global_property:
     loadp CodeBlock[cfr], t1
     loadp CodeBlock::m_globalObject[t1], t1
     loadp ResolveOperation::m_structure[t0], t2
-    bpneq JSCell::m_structure[t1], t2, _llint_op_resolve
+    bpneq JSCell::m_structure[t1], t2, ._llint_op_resolve
     loadis ResolveOperation::m_offset[t0], t0
     if JSVALUE64
         loadPropertyAtVariableOffsetKnownNotInline(t0, t1, t2)
@@ -746,6 +746,7 @@ _llint_op_resolve_scoped_var_with_top_scope_check:
     moveJSValue(t1, t2, cfr, t3, 4, t0)
     dispatch(5)
 
+._llint_op_resolve:
 _llint_op_resolve:
     traceExecution()
     getResolveOperation(3, t0, t1)
@@ -780,7 +781,7 @@ _llint_op_resolve_base_to_global:
     dispatch(7)
 
 _llint_op_resolve_base_to_global_dynamic:
-    jmp _llint_op_resolve_base
+    jmp ._llint_resolve_base
 
 _llint_op_resolve_base_to_scope:
     traceExecution()
@@ -827,6 +828,7 @@ _llint_op_resolve_base_to_scope_with_top_scope_check:
     end
     dispatch(7)
 
+._llint_resolve_base:
 _llint_op_resolve_base:
     traceExecution()
     callSlowPath(_llint_slow_path_resolve_base)


But I'm not familiar enough with LLInt to be sure that this is the right solution.

[Simon Hausmann]

Created attachment 170617 [details]
Workaround as attachment

[Mark Lam]

The proper fix is awaiting review at <https://bugs.webkit.org/show_bug.cgi?id=100345>.

*** This bug has been marked as a duplicate of bug 100345 ***