Chung-Lin Tang <clt...@codesourcery.com> writes: >> __builtin_thread_pointer is logically a separate patch anyway. >> In case it isn't clear, the reason I'm pushing back about the >> target-dependent thing is that you're adding a fair bit of extra >> code to the general MIPS built-in infrastructure in order to >> handle the set of "__builtin_thread_pointer-like functions". >> And my concern is that that set probably contains just one function. > > Well, some other architectures also have __builtin_set_thread_pointer(), > as you probably also noticed. The thing is that, unlike the > __builtin_return_address(), __builtin_saveregs() you mentioned, there > seems no general concept of the TLS environment exposed by the backend > (as opposed to things like frame-pointers, return-addr), so the > machine-independent code can't properly do things at arm's length. > > For a gcc/builtins.c expand function for __builtin_thread_pointer(), > it's probably either a target-hook or "sorry not implemented". That's > probably still okay, though I'm not sure it's the intended style.
FWIW, I think it's both OK and the way these things are supposed to work. The same would apply to __builtin_set_thread_pointer() like you say. We certainly have other sorry()s related to TLS, such as trying to declare TLS common data when that isn't supported. Richard
