| author |  Brandon Black <bblack@wikimedia.org> 2026-03-30 07:01:40-05:00 |
| committer | Brandon Black <bblack@wikimedia.org> 2026-03-31 14:48:03-05:00 |
| log | 1226bb9268f20740a69afd3097d40b4d3e371647 |
| tree | 42e6d115d9aacb0c8b453e8751bdf7e08c67dcdb |
| parent | 614cd66e7e9b7323dd67bf208fda9abf296721b4 |
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
lib/std/Thread.zig+1-1
| ... | ... | @@ -1489,7 +1489,7 @@ const LinuxThreadImpl = struct { |
| 1489 | 1489 | } |
| 1490 | 1490 | |
| 1491 | 1491 | // 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 | 1493 | var user_desc: if (target.cpu.arch == .x86) linux.user_desc else void = undefined; |
| 1494 | 1494 | if (target.cpu.arch == .x86) { |
| 1495 | 1495 | defer tls_ptr = @intFromPtr(&user_desc); |