authorgravatar for bblack@wikimedia.orgBrandon Black <bblack@wikimedia.org> 2026-03-30 07:01:40-05:00
committergravatar for bblack@wikimedia.orgBrandon Black <bblack@wikimedia.org> 2026-03-31 14:48:03-05:00
log1226bb9268f20740a69afd3097d40b4d3e371647
tree42e6d115d9aacb0c8b453e8751bdf7e08c67dcdb
parent614cd66e7e9b7323dd67bf208fda9abf296721b4

LinuxThreadImpl: be precise in tls.prepareArea arg

This isn't causing any functional problem today, but technically `mapped[tls_offset..]` runs past the tls part of `mapped` and into the `Instance` storage, and currently `prepareArea()` memsets its entire argument to zero. It is only the current layout and initialization order of `mapped` that prevents this from being a problem. Being more precise here avoids future footguns if any of that changes.

1 files changed, 1 insertions(+), 1 deletions(-)

lib/std/Thread.zig+1-1
...@@ -1489,7 +1489,7 @@ const LinuxThreadImpl = struct {...@@ -1489,7 +1489,7 @@ const LinuxThreadImpl = struct {
1489 }1489 }
14901490
1491 // Prepare the TLS segment and prepare a user_desc struct when needed on x861491 // Prepare the TLS segment and prepare a user_desc struct when needed on x86
1492 var tls_ptr = linux.tls.prepareArea(mapped[tls_offset..]);1492 var tls_ptr = linux.tls.prepareArea(mapped[tls_offset..][0..linux.tls.area_desc.size]);
1493 var user_desc: if (target.cpu.arch == .x86) linux.user_desc else void = undefined;1493 var user_desc: if (target.cpu.arch == .x86) linux.user_desc else void = undefined;
1494 if (target.cpu.arch == .x86) {1494 if (target.cpu.arch == .x86) {
1495 defer tls_ptr = @intFromPtr(&user_desc);1495 defer tls_ptr = @intFromPtr(&user_desc);