\o/ i've been looking for how to do that on x86 for ages. thank you.
-
-
-
This is not how. It will generate nonsense asm with -fPIC and possibly other circumstances.
-
I agree it's gross, but it's also sort of neat. Arguably it has teaching value -- can discuss why it works and why it's not ideal. Maybe better to stick to the TLS ABI and just do extern __thread... can still layout the kernel TLS area manually if you like (with --defsym even).
-
Note that this was eliminated in the MIT xv6 code base at the beginning of this year. https://github.com/mit-pdos/xv6-public/commit/7e0cc8e36ea91d0299f375f3b3476ab58ab71dde#diff-62a197b4710d3ed3ab9a258d55f686ce … is where it was introduced and https://github.com/mit-pdos/xv6-public/commit/abf847a083888bbed4260ecacf849ea19f23e810#diff-62a197b4710d3ed3ab9a258d55f686ce … removed it. Interestingly before that they *were* using __thread – not sure why they stopped.
-
Interestingly they also experimented keeping curproc at the top of the stack, which is what Linux has historically done (now IIRC Linux uses %gs on x86, but still stores the data structure in the same place, so the ESP & (THREAD_SIZE-1) trick still works).https://github.com/mit-pdos/xv6-public/commit/ce2e7515552adca3a60e349de2931112736d17bf#diff-62a197b4710d3ed3ab9a258d55f686ce …
-
Anyway, perhaps
@_rsc can be convinced to join the thread and talk about the history? -
It's a teaching operating system. It's meant to be simple. Why worry about explaining what the "TLS ABI" is when there is no other code running on the machine.
-
It's the abuse of asm names that allows for silent codegen breakage that I'm concerned about, not lack of "TLS ABI".
- 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.