[wpe-2.46][ARMv7] JSC build fail with Clang 20 and later

[emutavchi]

Build fails while compiling generated LLIntAssembly.h with an error 'Relocation Not In Range'

<inline asm>:320:49: error: Relocation Not In Range
  320 | movw r4, #:lower16:.Lllint_op_tail_call_varargs - .Lllint_relativePCBase 
      |                                                 ^
<inline asm>:321:49: error: Relocation Not In Range
  321 | movt r4, #:upper16:.Lllint_op_tail_call_varargs - .Lllint_relativePCBase 
...

which may be related to llvm/llvm-project@a4d6fe5 and mvlbl implementation for ARMv7 (see setEntryAddressCommon in LowLevelInterpreter.asm)

To reproduce the JSC build error, you'll also need some build fixes backported from upstream for WTF, see attached

wtf_clang_20.patch

[justinmichaud]

Brainstorming for the investigation with Angelos:

1. A symbol missing USED_FROM_ASM can cause llint symbols to be incorrectly relocated.
2. We should see how big the llint region actually is in the binary, in case it really is too big.

[justinmichaud]

I believe I have fixed this, I am just testing the fix

[justinmichaud]

I will submit this patch once I verify it works, but just in case you are blocked:

diff --git a/Source/JavaScriptCore/llint/LowLevelInterpreter.asm b/Source/JavaScriptCore/llint/LowLevelInterpreter.asm
index 4897373779bf..a00e5b942d4c 100644
--- a/Source/JavaScriptCore/llint/LowLevelInterpreter.asm
+++ b/Source/JavaScriptCore/llint/LowLevelInterpreter.asm
@@ -2190,7 +2190,7 @@ else
             leap (label - _%kind%_relativePCBase)[t3], t4
             move index, t5
             storep t4, [map, t5, 8]
-        elsif ARM64 or RISCV64
+        elsif ARM64 or RISCV64 or ARMv7
             pcrtoaddr label, t3
             move index, t4
             storep t3, [map, t4, PtrSize]
@@ -2200,11 +2200,6 @@ else
             leap [map, t4, PtrSize], t4
             tagCodePtr t3, BytecodePtrTag, AddressDiversified, t4
             storep t3, [t4]
-        elsif ARMv7
-            mvlbl (label - _%kind%_relativePCBase), t4
-            addp t4, t3, t4
-            move index, t5
-            storep t4, [map, t5, 4]
         end
     end

diff --git a/Source/JavaScriptCore/offlineasm/arm.rb b/Source/JavaScriptCore/offlineasm/arm.rb
index adc2cba6aa86..7498d6b7c6ba 100644
--- a/Source/JavaScriptCore/offlineasm/arm.rb
+++ b/Source/JavaScriptCore/offlineasm/arm.rb
@@ -765,9 +765,6 @@ class Instruction
             raise "First operand of moveii must be an immediate" unless operands[0].immediate?
             armMoveImmediate(operands[0].value >> 32, operands[1])
             armMoveImmediate(operands[0].value & 0xffffffff, operands[2])
-        when "mvlbl"
-                $asm.puts "movw #{operands[1].armOperand}, \#:lower16:#{operands[0].value}"
-                $asm.puts "movt #{operands[1].armOperand}, \#:upper16:#{operands[0].value}"
         when "sxb2i"
             $asm.puts "sxtb #{armFlippedOperands(operands)}"
         when "sxh2i"
@@ -954,6 +951,8 @@ class Instruction
             $asm.puts "dmb ishst"
         when "clrbp"
             $asm.puts "bic #{operands[2].armOperand}, #{operands[0].armOperand}, #{operands[1].armOperand}"
+        when "pcrtoaddr"
+            $asm.puts "adr #{operands[1].armOperand}, #{operands[0].value}"
         when "globaladdr"
             labelRef = operands[0]
             dest = operands[1]
@@ -1011,4 +1010,3 @@ class Instruction
         end
     end
 end
-
diff --git a/Source/JavaScriptCore/offlineasm/instructions.rb b/Source/JavaScriptCore/offlineasm/instructions.rb
index da4d19ab59f0..5194a2f1ef06 100644
--- a/Source/JavaScriptCore/offlineasm/instructions.rb
+++ b/Source/JavaScriptCore/offlineasm/instructions.rb
@@ -394,7 +394,6 @@ ARM_INSTRUCTIONS =
      "adci",
      "bcs",
      "clrbp",
-     "mvlbl",
      "globaladdr",
      "sbci",
      "moveii",

But I haven't confirmed that this actually runs yet, I should be able to finish it tomorrow morning.

[justinmichaud]

Quick status update: this fixes the build issue, but some symbols are still getting relocated, causing LLInt to fail at runtime. Still investigating.

[justinmichaud]

We have a separate issue upstream complicating things, but I think this should do the trick: #1606

Upstream, this fix will land in WebKit/WebKit#56833

[justinmichaud]

I was getting very confused by this. I was getting strange crashes that didn't make sense, but directly comparing the two relocation methods with clang 19 showed no difference in the produced value.

Anyway, I figured it out and it is really silly: for some reason, my debug build (clang-20 + gnu linker, since ldd runs out of memory) wasn't emitting the correct thumb bits for these relocations. With -mthumb in my cxx and ld flags, everything worked out.

Everything should land shortly, and be ready for you Monday morning.

[justinmichaud]

I am now trying to reproduce your WTF failures.