LLVM emits broken TLS access sequence on aarch64-windows for private thread_locals mixed with non-private ones #31865

As far as I can tell, literally any invocation results in this:

"C:\a\zig-sdk\zig-sdk\out\dep\vezel.zig.toolsets.win-arm640円.16.0.1\tools\zig.exe" exited with code -1073741819.

We are working on acquiring AArch64 hardware that, among other platform coverage, will allow us to resurrect aarch64-windows CI. But until then, I don't have access to a machine I can debug this on, so would appreciate any help in fixing this.

x86_64 cross-compiling to aarch64 works correctly.

- uses:mlugg/setup-zig@v2if:matrix.os != 'windows-11-arm'- name:Setup zig (Windows ARM workaround)if:matrix.os == 'windows-11-arm'run:| curl -fsSLo zig.zip https://ziglang.org/download/0.16.0/zig-x86_64-windows-0.16.0.zip
 unzip -q zig.zip -d zig-sdk
 echo "$PWD/zig-sdk/zig-x86_64-windows-0.16.0" >> $GITHUB_PATH

Probably aarch64-windows bootstrap package needs to be rebuilt from x86_64.

src/codegen/llvm.zig

- .internal => if (o.builder.strip) .private else .internal,
+ .internal => if (o.builder.strip and !resolved.@"threadlocal") .private else .internal,

- llvm_global.ptr(&o.builder).linkage = if (o.builder.strip) .private else .internal;
+ llvm_global.ptr(&o.builder).linkage = if (o.builder.strip and !resolved.@"threadlocal") .private else .internal;

this worked for me. rebuilt from source with this edit, no errors using new binary on aarch64-windows to compile my projects

I've been using this patched version of the compiler for a couple of weeks now without any issue. Builds DVUI and other projects successfully.

threadlocalvarx:u32=undefined;pubexportfnfoo()u32{returnx;}

zig4 build-lib -dynamic repro.zig -target aarch64-windows-gnu -lc:

0010fdf0 uint32_t foo()
0010fdf0 fd7bbfa9 stp fp, lr, [sp, #-0x10]! {__saved_fp} {__saved_lr}
0010fdf4 fd030091 mov fp, sp {__saved_fp}
0010fdf8 482e40f9 ldr x8, [x18, #0x58]
0010fdfc c90400f0 adrp x9, global_single_threaded_instance.csprng.rng.__offset(0x190)
0010fe00 294d42b9 ldr w9, [x9, #0x24c] {_tls_index}
0010fe04 087969f8 ldr x8, [x8, x9, lsl #0x3]
0010fe08 08014091 add x8, x8, #0, lsl #0xc
0010fe0c 001940b9 ldr w0, [x8, #0x18]
0010fe10 fd7bc1a8 ldp fp, lr, [sp], #0x10 {__saved_fp} {__saved_lr}
0010fe14 c0035fd6 ret 

zig4 build-lib -dynamic repro.zig -target aarch64-windows-gnu -lc -fstrip:

0009c9e8 uint32_t foo()
0009c9e8 fd7bbfa9 stp fp, lr, [sp, #-0x10]! {__saved_fp} {__saved_lr}
0009c9ec fd030091 mov fp, sp {__saved_fp}
0009c9f0 482e40f9 ldr x8, [x18, #0x58]
0009c9f4 090300b0 adrp x9, data_fd000
0009c9f8 29e541b9 ldr w9, [x9, #0x1e4] {data_fd1e4}
0009c9fc 087969f8 ldr x8, [x8, x9, lsl #0x3]
0009ca00 08414091 add x8, x8, #0x10, lsl #0xc
0009ca04 001940b9 ldr w0, [x8, #0x18]
0009ca08 fd7bc1a8 ldp fp, lr, [sp], #0x10 {__saved_fp} {__saved_lr}
0009ca0c c0035fd6 ret 

That add x8, x8, #0x10, lsl #0xc is very wrong; both DLLs have a .tls section that's 40 bytes in size, and x should be at offset zero in that section in both cases.

Still no idea why this is happening.

AArch64AsmBackend.cpp

rebuilt LLVM 22.1.3 with this and reprods compile clean:

 case AArch64::fixup_aarch64_add_imm12:
 case AArch64::fixup_aarch64_ldst_imm12_scale1:
- if (TheTriple.isOSBinFormatCOFF() && !IsResolved)
+ if (TheTriple.isOSBinFormatCOFF() && !IsResolved) {
+ if (AArch64::getAddressFrag(static_cast<AArch64::Specifier>(
+ Target.getSpecifier())) == AArch64::S_HI12)
+ Value >>= 12;
 Value &= 0xfff;
+ }

i have a snapdragon x2ee laptop if you want me to test anything else on my hardware, let me know

Reduction:

; ModuleID = 'reduced.bc'
target datalayout = "e-m:w-p270:32:32-p271:32:32-p272:64:64-p:64:64-i32:32-i64:64-i128:128-n32:64-S128-Fn32"
target triple = "aarch64-unknown-windows-gnu"
@debug.panic_stage = thread_local global i64 0
@repro.x = private thread_local global i32 undef
@foo = alias i32 (), ptr @repro.foo
define i32 @repro.foo() {
 %1 = load i32, ptr @repro.x, align 4
 ret i32 %1
}

❯ llc reduced.bc -filetype obj
❯ llvm-objdump --disassemble-symbols=foo reduced.obj
reduced.obj: file format coff-arm64
Disassembly of section .text:
0000000000000000 <foo>:
 0: 90000008 adrp x8, 0x0 <repro.foo>
 4: f9402e49 ldr x9, [x18, #0x58]
 8: b9400108 ldr w8, [x8]
 c: f8687928 ldr x8, [x9, x8, lsl #3]
 10: 91402108 add x8, x8, #0x8, lsl #12 // =0x8000
 14: b9400900 ldr w0, [x8, #0x8]
 18: d65f03c0 ret

https://github.com/llvm/llvm-project/issues/199581

this issue was resolved on the LLVM side with two commits, see https://github.com/llvm/llvm-project/issues/199581