[PATCH] Add support for accessing the FS segment register on X86

Hi,

The attached patch adds support for accessing the FS segment register using address space 255, similarly to the way the GS segment register can be accessed. This is useful for generating TLS access code on amd64 for example.

Zoltan

fs.diff (6.4 KB)

Maybe 257 would be better (or other unused), because of r70197, which gives special behavior for <256

Shantonu Sen
ssen@apple.com

fs.diff (6.4 KB)

Hi,

Here is an updated version of the patch using address space 257.

Zoltan

fs.diff (3.44 KB)

Hello,

The preferred way to do TLS is to use the thread_local keyword.
There is x86-64 support for thread_local on ELF; if you need
it for other targets, I recommend looking at adapting it.

Dan

That said, the X86 backend supporting access off FS is general goodness, right?

-Chris

Hi,

If I’m writing a JIT, and want to access the TLS variables of the app containing the JIT, I can’t
use thread_local since that only works for variables declared in LLVM IL and/or managed by
the ExecutionEngine. While this patch allows a JIT to generate the TLS accesses itself, if
it knows the tls offset of the variable in question.

Zoltan

Please consider changing clang to expose this functionality via names,
rather than magic numbers. The fact that clang has chosen to expose
x86 esoterica via LLVM-specific magic numbers is distasteful.

Also, please add a note in clang's manual that address-spaces are not
intended to be used for normal TLS. They don't actually work the same
way, and this fact is non-obvious.

Further, please document that address-space qualifiers on variables
with static storage are not actually handled specially. So something
like "address_space(256) int x; address_space(256) int *y = &x" does
not actually result in y pointing at x. Actually, please change the
front-end to outright disallow this.

Do all of those things, and I may agree :-).

Dan

I ultimately don't object to this patch.

I see now that thread_local is not fully supported on x86-64 in
the JIT. As a theoretical question however, would that not
provide the needed functionality? The JIT can easily get the
address for variables declared in the LLVM IR.

Also, be aware of PR3966.

Dan

Applied, thanks!
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090504/077147.html

-Chris