ziglang/zig
259
6.0k
Fork
You've already forked zig
772

Prevent register clobbering on x86_64 threadlocal access #30202

Merged
mlugg merged 1 commit from sphaerophoria/zig:fix-30183 into master 2025年12月17日 15:33:13 +01:00
Contributor
Copy link

On the x86_64 self hosted backend, thread locals are accessed through
__tls_get_addr on PIC. Usually this goes through a fast path which does
not lose any registers, however in some cases (notably any dlopened
library on my machine) this can take a slow path which calls out to C
ABI functions

Catch this case and backup registers as necessary

Fixes #30183

On the x86_64 self hosted backend, thread locals are accessed through __tls_get_addr on PIC. Usually this goes through a fast path which does not lose any registers, however in some cases (notably any dlopened library on my machine) this can take a slow path which calls out to C ABI functions Catch this case and backup registers as necessary Fixes #30183
Author
Contributor
Copy link

Some concerns I have with this PR, but don't know if are warranted due to unfamiliarity with the codebase

  1. the knowledge of the __tls_get_addr call and it's behavior are now spread across multiple areas. I was kinda just going with the flow here copying the other spill list for coff/pic
  2. I'm unsure if I should be pulling the register list from somewhere, right now I just wrote down the 6 I see in systemv's callconv
  3. My gut says that the real correct answer is to re-use the logic in genCall() somehow. Like in this case this should be 1-1 to a C ABI fn call. I could see an argument that it's a very specific case though so dodging all that logic is fine
Some concerns I have with this PR, but don't know if are warranted due to unfamiliarity with the codebase 1. the knowledge of the __tls_get_addr call and it's behavior are now spread across multiple areas. I was kinda just going with the flow here copying the other spill list for coff/pic 2. I'm unsure if I should be pulling the register list from somewhere, right now I just wrote down the 6 I see in systemv's callconv 3. My gut says that the real correct answer is to re-use the logic in genCall() somehow. Like in this case this should be 1-1 to a C ABI fn call. I could see an argument that it's a very specific case though so dodging all that logic is fine
Owner
Copy link

the knowledge of the __tls_get_addr call and it's behavior are now spread across multiple areas.

This is true, but I think it's fine for now. After all, the old (incorrect) clobber lists were also duplicating information about the TLS lowering.

I'm unsure if I should be pulling the register list from somewhere
[...]
My gut says that the real correct answer is to re-use the logic in genCall() somehow

The relevant lines of genCall are these two:

tryself.spillEflagsIfOccupied();tryself.spillCallerPreservedRegs(fn_info.cc,call_info.err_ret_trace_reg);

The first one is actually missing from TLS logic, that should probably also be there. But focusing on the second: because we're calling a C ABI function, we know that err_ret_trace_reg is .none (you can search through resolveCallingConventionValues to confirm that), and looking at the body of spillCallerPreservedRegs we see that this case is basically equivalent to self.spillRegisters(abi.getCallerPreservedRegs(cc_tag)); and here the calling convention is gonna be .x86_64_sysv, so we should be able to do cg.spillRegisters(abi.getCallerPreservedRegs(.x86_64_sysv)).


I just spent a little while looking at all of the current TLS lowerings and figuring out the correct clobbers. I haven't tested it even slightly, but I'm pretty sure this would be the fully-correct logic:

if(is_threadlocal)switch(cg.target.ofmt){.elf=>if(cg.mod.pic){// LD model: `__tls_get_addr` uses the standard ABItrycg.spillRegisters(abi.getCallerPreservedRegs(.x86_64_sysv));trycg.spillEflagsIfOccupied();}else{// LE model: manual lowering uses these two registerstrycg.spillRegisters(&.{.rdi,.rax});},.coff=>{// manual lowering uses these registerstrycg.spillRegisters(&.{.rdi,.rax});},.macho=>switch(cg.target.arch){.x86=>{// `tlv_get_addr` returns in eax, clobbers ecx, preserves other GPRstrycg.spillRegisters(&.{.rax,.rcx});trycg.spillEflagsIfOccupied();},.x86_64=>{// `tlv_get_addr` returns in rax, preserves other GPRstrycg.spillRegisters(&.{.rax});trycg.spillEflagsIfOccupied();},},else=>unreachable,};

(regarding that last Mach-O case, the backend doesn't really support arch == .x86 right now, but no harm working towards that support a little bit)

> the knowledge of the __tls_get_addr call and it's behavior are now spread across multiple areas. This is true, but I think it's fine for now. After all, the old (incorrect) clobber lists were also duplicating information about the TLS lowering. > I'm unsure if I should be pulling the register list from somewhere > [...] > My gut says that the real correct answer is to re-use the logic in genCall() somehow The relevant lines of `genCall` are these two: ```zig try self.spillEflagsIfOccupied(); try self.spillCallerPreservedRegs(fn_info.cc, call_info.err_ret_trace_reg); ``` The first one is actually missing from TLS logic, that should probably also be there. But focusing on the second: because we're calling a C ABI function, we know that `err_ret_trace_reg` is `.none` (you can search through `resolveCallingConventionValues` to confirm that), and looking at the body of `spillCallerPreservedRegs` we see that this case is basically equivalent to `self.spillRegisters(abi.getCallerPreservedRegs(cc_tag))`; and here the calling convention is gonna be `.x86_64_sysv`, so we should be able to do `cg.spillRegisters(abi.getCallerPreservedRegs(.x86_64_sysv))`. --- I just spent a little while looking at all of the current TLS lowerings and figuring out the correct clobbers. I haven't tested it even slightly, but I'm pretty sure this would be the fully-correct logic: ```zig if (is_threadlocal) switch (cg.target.ofmt) { .elf => if (cg.mod.pic) { // LD model: `__tls_get_addr` uses the standard ABI try cg.spillRegisters(abi.getCallerPreservedRegs(.x86_64_sysv)); try cg.spillEflagsIfOccupied(); } else { // LE model: manual lowering uses these two registers try cg.spillRegisters(&.{ .rdi, .rax }); }, .coff => { // manual lowering uses these registers try cg.spillRegisters(&.{ .rdi, .rax }); }, .macho => switch (cg.target.arch) { .x86 => { // `tlv_get_addr` returns in eax, clobbers ecx, preserves other GPRs try cg.spillRegisters(&.{ .rax, .rcx }); try cg.spillEflagsIfOccupied(); }, .x86_64 => { // `tlv_get_addr` returns in rax, preserves other GPRs try cg.spillRegisters(&.{.rax}); try cg.spillEflagsIfOccupied(); }, }, else => unreachable, }; ``` (regarding that last Mach-O case, the backend doesn't really support `arch == .x86` right now, but no harm working towards that support a little bit)
sphaerophoria force-pushed fix-30183 from e41f012ae5
All checks were successful
ci / riscv64-linux-debug (pull_request) Has been skipped
ci / riscv64-linux-release (pull_request) Has been skipped
ci / x86_64-freebsd-release (pull_request) Successful in 47m17s
ci / x86_64-windows-release (pull_request) Successful in 50m59s
ci / x86_64-freebsd-debug (pull_request) Successful in 54m29s
ci / x86_64-windows-debug (pull_request) Successful in 59m5s
ci / aarch64-macos-release (pull_request) Successful in 1h0m49s
ci / x86_64-linux-debug (pull_request) Successful in 1h12m44s
ci / s390x-linux-release (pull_request) Successful in 1h22m28s
ci / aarch64-linux-release (pull_request) Successful in 1h23m57s
ci / aarch64-linux-debug (pull_request) Successful in 1h51m6s
ci / aarch64-macos-debug (pull_request) Successful in 1h53m39s
ci / loongarch64-linux-release (pull_request) Successful in 2h3m34s
ci / s390x-linux-debug (pull_request) Successful in 2h35m13s
ci / x86_64-linux-release (pull_request) Successful in 2h59m21s
ci / x86_64-linux-debug-llvm (pull_request) Successful in 3h2m2s
ci / loongarch64-linux-debug (pull_request) Successful in 3h6m52s
to db8afa75d5
All checks were successful
ci / riscv64-linux-debug (pull_request) Has been skipped
ci / riscv64-linux-release (pull_request) Has been skipped
ci / x86_64-freebsd-release (pull_request) Successful in 31m30s
ci / x86_64-linux-debug (pull_request) Successful in 36m40s
ci / x86_64-windows-release (pull_request) Successful in 43m48s
ci / aarch64-macos-release (pull_request) Successful in 43m8s
ci / x86_64-freebsd-debug (pull_request) Successful in 45m9s
ci / x86_64-windows-debug (pull_request) Successful in 48m23s
ci / aarch64-linux-release (pull_request) Successful in 1h17m12s
ci / aarch64-macos-debug (pull_request) Successful in 1h30m51s
ci / aarch64-linux-debug (pull_request) Successful in 1h46m50s
ci / s390x-linux-release (pull_request) Successful in 1h47m6s
ci / loongarch64-linux-release (pull_request) Successful in 1h48m18s
ci / x86_64-linux-debug-llvm (pull_request) Successful in 1h57m39s
ci / x86_64-linux-release (pull_request) Successful in 2h8m16s
ci / s390x-linux-debug (pull_request) Successful in 2h22m13s
ci / loongarch64-linux-debug (pull_request) Successful in 3h15m46s
2025年12月16日 19:55:50 +01:00
Compare
Author
Contributor
Copy link

Thanks for taking a peek :)

The first one is actually missing from TLS logic, that should probably also be there

Oops, agreed.

because we're calling a C ABI function, we know that err_ret_trace_reg is .none

Ah yeah I thought it was more complicated and this block was related below as well

 if (call_info.err_ret_trace_reg != .none) {
 if (self.inst_tracking.getPtr(err_ret_trace_index)) |err_ret_trace| {
 if (switch (err_ret_trace.short) {
 .register => |reg| call_info.err_ret_trace_reg != reg,
 else => true,
 }) {
 try self.register_manager.getReg(call_info.err_ret_trace_reg, err_ret_trace_index);
 try reg_locks.append(self.register_manager.lockReg(call_info.err_ret_trace_reg));
 try self.genSetReg(call_info.err_ret_trace_reg, .usize, err_ret_trace.short, .{});
 err_ret_trace.trackMaterialize(err_ret_trace_index, .{
 .long = err_ret_trace.long,
 .short = .{ .register = call_info.err_ret_trace_reg },
 });
 }
 }
 }

but now I'm noticing the difference between call_info.err_ret_trace_index and self.err_ret_trace_reg. Somehow I got those tangled in my head

Agreed with your x86_64 impl, and choosing to trust you on the others. (with a s/target.arch/cpu.target.arch/ and an extra unreachable).

Thanks for taking a peek :) > The first one is actually missing from TLS logic, that should probably also be there Oops, agreed. > because we're calling a C ABI function, we know that err_ret_trace_reg is .none Ah yeah I thought it was more complicated and this block was related below as well ``` if (call_info.err_ret_trace_reg != .none) { if (self.inst_tracking.getPtr(err_ret_trace_index)) |err_ret_trace| { if (switch (err_ret_trace.short) { .register => |reg| call_info.err_ret_trace_reg != reg, else => true, }) { try self.register_manager.getReg(call_info.err_ret_trace_reg, err_ret_trace_index); try reg_locks.append(self.register_manager.lockReg(call_info.err_ret_trace_reg)); try self.genSetReg(call_info.err_ret_trace_reg, .usize, err_ret_trace.short, .{}); err_ret_trace.trackMaterialize(err_ret_trace_index, .{ .long = err_ret_trace.long, .short = .{ .register = call_info.err_ret_trace_reg }, }); } } } ``` but now I'm noticing the difference between call_info.err_ret_trace_index and self.err_ret_trace_reg. Somehow I got those tangled in my head Agreed with your x86_64 impl, and choosing to trust you on the others. (with a s/target.arch/cpu.target.arch/ and an extra unreachable).
jacobly requested changes 2025年12月16日 22:28:23 +01:00
Dismissed
jacobly left a comment
Copy link

Since you are not locking any registers, spillEflagsIfOccupied has to be before spillRegisters.

Since you are not locking any registers, `spillEflagsIfOccupied` has to be before `spillRegisters`.
sphaerophoria force-pushed fix-30183 from db8afa75d5
All checks were successful
ci / riscv64-linux-debug (pull_request) Has been skipped
ci / riscv64-linux-release (pull_request) Has been skipped
ci / x86_64-freebsd-release (pull_request) Successful in 31m30s
ci / x86_64-linux-debug (pull_request) Successful in 36m40s
ci / x86_64-windows-release (pull_request) Successful in 43m48s
ci / aarch64-macos-release (pull_request) Successful in 43m8s
ci / x86_64-freebsd-debug (pull_request) Successful in 45m9s
ci / x86_64-windows-debug (pull_request) Successful in 48m23s
ci / aarch64-linux-release (pull_request) Successful in 1h17m12s
ci / aarch64-macos-debug (pull_request) Successful in 1h30m51s
ci / aarch64-linux-debug (pull_request) Successful in 1h46m50s
ci / s390x-linux-release (pull_request) Successful in 1h47m6s
ci / loongarch64-linux-release (pull_request) Successful in 1h48m18s
ci / x86_64-linux-debug-llvm (pull_request) Successful in 1h57m39s
ci / x86_64-linux-release (pull_request) Successful in 2h8m16s
ci / s390x-linux-debug (pull_request) Successful in 2h22m13s
ci / loongarch64-linux-debug (pull_request) Successful in 3h15m46s
to e2c54e187f
Some checks failed
ci / riscv64-linux-debug (pull_request) Has been skipped
ci / riscv64-linux-release (pull_request) Has been skipped
ci / x86_64-freebsd-release (pull_request) Successful in 39m42s
ci / loongarch64-linux-debug (pull_request) Has been cancelled
ci / loongarch64-linux-release (pull_request) Has been cancelled
ci / aarch64-linux-debug (pull_request) Has been cancelled
ci / aarch64-linux-release (pull_request) Has been cancelled
ci / x86_64-linux-debug (pull_request) Has been cancelled
ci / x86_64-freebsd-debug (pull_request) Has been cancelled
ci / x86_64-windows-debug (pull_request) Has been cancelled
ci / x86_64-windows-release (pull_request) Has been cancelled
ci / x86_64-linux-debug-llvm (pull_request) Has been cancelled
ci / x86_64-linux-release (pull_request) Has been cancelled
ci / aarch64-macos-debug (pull_request) Has been cancelled
ci / s390x-linux-release (pull_request) Has been cancelled
ci / s390x-linux-debug (pull_request) Has been cancelled
ci / aarch64-macos-release (pull_request) Has been cancelled
2025年12月16日 23:27:59 +01:00
Compare
Owner
Copy link

You missed the other two spillEflagsIfOccupied calls @sphaerophoria

You missed the other two `spillEflagsIfOccupied` calls @sphaerophoria
Author
Contributor
Copy link

😬I actually looked at them and for some reason they registered in my head as already correct. That's somehow more embarrassing than just forgetting. Sorry for wasting CI time

😬I actually looked at them and for some reason they registered in my head as already correct. That's somehow more embarrassing than just forgetting. Sorry for wasting CI time
sphaerophoria force-pushed fix-30183 from e2c54e187f
Some checks failed
ci / riscv64-linux-debug (pull_request) Has been skipped
ci / riscv64-linux-release (pull_request) Has been skipped
ci / x86_64-freebsd-release (pull_request) Successful in 39m42s
ci / loongarch64-linux-debug (pull_request) Has been cancelled
ci / loongarch64-linux-release (pull_request) Has been cancelled
ci / aarch64-linux-debug (pull_request) Has been cancelled
ci / aarch64-linux-release (pull_request) Has been cancelled
ci / x86_64-linux-debug (pull_request) Has been cancelled
ci / x86_64-freebsd-debug (pull_request) Has been cancelled
ci / x86_64-windows-debug (pull_request) Has been cancelled
ci / x86_64-windows-release (pull_request) Has been cancelled
ci / x86_64-linux-debug-llvm (pull_request) Has been cancelled
ci / x86_64-linux-release (pull_request) Has been cancelled
ci / aarch64-macos-debug (pull_request) Has been cancelled
ci / s390x-linux-release (pull_request) Has been cancelled
ci / s390x-linux-debug (pull_request) Has been cancelled
ci / aarch64-macos-release (pull_request) Has been cancelled
to e43bee617a
All checks were successful
ci / riscv64-linux-debug (pull_request) Has been skipped
ci / riscv64-linux-release (pull_request) Has been skipped
ci / x86_64-freebsd-release (pull_request) Successful in 34m54s
ci / x86_64-windows-release (pull_request) Successful in 43m38s
ci / x86_64-freebsd-debug (pull_request) Successful in 43m43s
ci / x86_64-windows-debug (pull_request) Successful in 45m24s
ci / aarch64-macos-release (pull_request) Successful in 54m2s
ci / x86_64-linux-debug (pull_request) Successful in 1h5m12s
ci / x86_64-linux-debug-llvm (pull_request) Successful in 1h12m35s
ci / aarch64-linux-release (pull_request) Successful in 1h21m45s
ci / aarch64-macos-debug (pull_request) Successful in 1h30m53s
ci / s390x-linux-release (pull_request) Successful in 1h31m26s
ci / aarch64-linux-debug (pull_request) Successful in 1h49m32s
ci / loongarch64-linux-release (pull_request) Successful in 2h2m6s
ci / s390x-linux-debug (pull_request) Successful in 2h21m33s
ci / x86_64-linux-release (pull_request) Successful in 2h44m17s
ci / loongarch64-linux-debug (pull_request) Successful in 3h6m3s
2025年12月17日 00:19:20 +01:00
Compare
Sign in to join this conversation.
No reviewers
Labels
Clear labels
abi/f32
abi/ilp32
abi/sf
accepted
This proposal is planned.
arch/21k
arch/6502
arch/aarch64
arch/alpha
arch/amdgcn
arch/arc
arch/arc32
arch/arc64
arch/arm
arch/avr
arch/bfin
arch/bpf
arch/colossus
arch/cris
arch/csky
arch/dlx
arch/epiphany
arch/fr30
arch/frv
arch/hexagon
arch/hppa
arch/hppa64
arch/ia64
arch/kalimba
arch/kvx
arch/lanai
arch/lm32
arch/loongarch32
arch/loongarch64
arch/m32r
arch/m68k
arch/m88k
arch/mcore
arch/microblaze
arch/mips
arch/mips64
arch/mmix
arch/moxie
arch/mrisc32
arch/msp430
arch/nds32
arch/ns32k
arch/nvptx
arch/or1k
arch/powerpc
arch/powerpc64
arch/propeller
arch/riscv32
arch/riscv64
arch/rl78
arch/rx
arch/s390x
arch/sh
arch/sparc
arch/sparc64
arch/spirv
arch/spu
arch/tricore
arch/v850
arch/vax
arch/vc4
arch/ve
arch/wasm
arch/x86
arch/x86_64
arch/xcore
arch/xtensa
autodoc
The web application for interactive documentation and generation of its assets.
backend/c
The C backend outputs C source code.
backend/llvm
The LLVM backend outputs an LLVM bitcode module.
backend/self-hosted
The self-hosted backends produce machine code directly.
binutils
Zig's included binary utilities: zig ar, zig dlltool, zig lib, zig ranlib, zig objcopy, and zig rc.
breaking
Implementing this issue could cause existing code to no longer compile or have different behavior.
build system
The Zig build system - zig build, std.Build, the build runner, and package management.
debug info
An issue related to debug information (e.g. DWARF) produced by the Zig compiler.
docs
An issue with documentation, e.g. the language reference or standard library doc comments.
error message
This issue points out an error message that is unhelpful and should be improved.
frontend
Tokenization, parsing, AstGen, ZonGen, Sema, Legalize, and Liveness.
fuzzing
An issue related to Zig's integrated fuzz testing.
incremental
Reuse of internal compiler state for faster compilation.
lib/c
This issue relates to Zig's libc implementation and/or vendored libcs.
lib/compiler-rt
This issue relates to Zig's compiler-rt library.
lib/cxx
This issue relates to Zig's vendored libc++ and/or libc++abi.
lib/std
This issue relates to Zig's standard library.
lib/tsan
This issue relates to Zig's vendored libtsan.
lib/ubsan-rt
This issue relates to Zig's ubsan-rt library.
lib/unwind
This issue relates to Zig's vendored libunwind.
linking
Zig's integrated object file and incremental linker.
miscompilation
The compiler reports success but produces semantically incorrect code.
os/android
os/contiki
os/dragonfly
os/driverkit
os/emscripten
os/freebsd
os/fuchsia
os/haiku
os/hermit
os/hurd
os/illumos
os/ios
os/linux
os/maccatalyst
os/macos
os/managarm
os/netbsd
os/ohos
os/openbsd
os/plan9
os/redox
os/rtems
os/serenity
os/tvos
os/uefi
os/visionos
os/wasi
os/watchos
os/windows
proposal
This issue suggests language modifications. If it also has the "accepted" label then it is planned.
release notes
This issue or pull request should be mentioned in the release notes.
testing
This issue is related to testing the compiler, standard library, or other parts of Zig.
zig cc
Zig as a drop-in C-family compiler.
zig fmt
The Zig source code formatter.
zig reduce
The Zig source code reduction tool.
bounty
https://ziglang.org/news/announcing-donor-bounties
bug
Observed behavior contradicts documented or intended behavior.
contributor-friendly
This issue is limited in scope and/or knowledge of project internals.
downstream
An issue with a third-party project that uses this project.
enhancement
Solving this issue will likely involve adding new logic or components to the codebase.
infra
An issue related to project infrastructure, e.g. continuous integration.
optimization
A task to improve performance and/or resource usage.
question
No questions on the issue tracker; use a community space instead.
regression
Something that used to work in a previous version stopped working
upstream
An issue with a third-party project that this project uses.
use case
Describes a real use case that is difficult or impossible, but does not propose a solution.
No labels
abi/f32
abi/ilp32
abi/sf
accepted
arch/21k
arch/6502
arch/aarch64
arch/alpha
arch/amdgcn
arch/arc
arch/arc32
arch/arc64
arch/arm
arch/avr
arch/bfin
arch/bpf
arch/colossus
arch/cris
arch/csky
arch/dlx
arch/epiphany
arch/fr30
arch/frv
arch/hexagon
arch/hppa
arch/hppa64
arch/ia64
arch/kalimba
arch/kvx
arch/lanai
arch/lm32
arch/loongarch32
arch/loongarch64
arch/m32r
arch/m68k
arch/m88k
arch/mcore
arch/microblaze
arch/mips
arch/mips64
arch/mmix
arch/moxie
arch/mrisc32
arch/msp430
arch/nds32
arch/ns32k
arch/nvptx
arch/or1k
arch/powerpc
arch/powerpc64
arch/propeller
arch/riscv32
arch/riscv64
arch/rl78
arch/rx
arch/s390x
arch/sh
arch/sparc
arch/sparc64
arch/spirv
arch/spu
arch/tricore
arch/v850
arch/vax
arch/vc4
arch/ve
arch/wasm
arch/x86
arch/x86_64
arch/xcore
arch/xtensa
autodoc
backend/c
backend/llvm
backend/self-hosted
binutils
breaking
build system
debug info
docs
error message
frontend
fuzzing
incremental
lib/c
lib/compiler-rt
lib/cxx
lib/std
lib/tsan
lib/ubsan-rt
lib/unwind
linking
miscompilation
os/android
os/contiki
os/dragonfly
os/driverkit
os/emscripten
os/freebsd
os/fuchsia
os/haiku
os/hermit
os/hurd
os/illumos
os/ios
os/linux
os/maccatalyst
os/macos
os/managarm
os/netbsd
os/ohos
os/openbsd
os/plan9
os/redox
os/rtems
os/serenity
os/tvos
os/uefi
os/visionos
os/wasi
os/watchos
os/windows
proposal
release notes
testing
zig cc
zig fmt
zig reduce
bounty
bug
contributor-friendly
downstream
enhancement
infra
optimization
question
regression
upstream
use case
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
ziglang/zig!30202
Reference in a new issue
ziglang/zig
No description provided.
Delete branch "sphaerophoria/zig:fix-30183"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?