Re:Rust's unsafe pointer types need an overhaul
by saagarjha on Sunday March 20, 2022 @02:28AM
(#30740606)
Segments are somewhat different on x86-64, which uses them to just compute a virtual address that you can just use as a normal pointer. There’s no “fat” pointer really involved here, the segment register just provides a convenient place to stash the base address of the TLS or whatever you’re using it for. This is why you can store a normal pointer that points into the TLS. This is different from segmentation in the past where you could really keep everything in your address space at once, so every use of the pointer required arithmetic, or with CHERI where you need to pass around the full “big” pointer to have the right capability to access the memory.
Re:Rust's unsafe pointer types need an overhaul
by zozbot234 on Sunday March 20, 2022 @10:46AM
(#30743031)
There are C embedded extensions for separate address spaces. So the idea is not totally new. But AIUI, the C extensions still require some way of converting a pointer in a specified address space to the usual "generic" pointer type where the address space could only be part of the vale.
Re:Rust's unsafe pointer types need an overhaul
by pjmlp on Sunday March 20, 2022 @02:43PM
(#30745367)
Just like on the 16 bit days there were near and far pointer extensions on MS-DOS and Windows 16 bit.
Re:Rust's unsafe pointer types need an overhaul
by mrlonglong on Wednesday March 23, 2022 @06:29PM
(#30784364)
And th choice of lovely memory models including tiny, small, medium, large and huge depending on the code and data sizes. Good times.
Re:Rust's unsafe pointer types need an overhaul
by staticassertion on Sunday March 20, 2022 @01:10AM
(#30740324)
> I regret to inform you that x86_64 (which is probably a “major architecture”) is segmented and has three address spaces.
Can you say more? I assumed the post was referring to segmentation registers, which are not an x86_64 thing.
Re:Rust's unsafe pointer types need an overhaul
by anonacct37 on Sunday March 20, 2022 @01:21AM
(#30740380)
amd64 uses segment registers for TLS (such as errno).
https://stackoverflow.com/questions/6611346/how-are-the-fs-g...
Re:Rust's unsafe pointer types need an overhaul
by Gankra on Sunday March 20, 2022 @01:38AM
(#30740436)
hmm i've always just mentally modelled TLS as "yeah the OS slaps a pointer to an array in this one register".
but i guess the difference between "pointer to an array" and "a segment of memory" isn't actually that big?
Re:Rust's unsafe pointer types need an overhaul
by amluto on Sunday March 20, 2022 @08:20AM
(#30742055)
It’s a funny register: you don’t want to read it (and before Ivy Bridge, user code couldn’t read it). The base is added by the CPU when you dereference the pointer. So code like:
__thread int array[100];
array[n] += 5:
Re:Rust's unsafe pointer types need an overhaul
by staticassertion on Sunday March 20, 2022 @01:22AM
(#30740386)
Thank you! I love learning about stuff like this but I wasn't sure what to search for. Much appreciated.
I regret to inform you that x86_64 (which is probably a “major architecture”) is segmented and has three address spaces. In practice, it has two. In user code, those address spaces are normal memory and TLS and, in kernel code, they are normal memory and percpu memory.
And the proposed scheme in this article is, on first read, amazing. It would make the epic hackery in the kernel percpu code safer (in Rust, anyway). The major caveat is that, for even slightly decent codegen, the address space of an x86_64 pointer should be part of its type, not its value. Even do, this scheme still works:
has a type! If the input pointer is TLS or percpu, so is the output.