Re: thread-local storage: c front end and generic backend patch

[Richard Henderson <rth at redhat dot com>]

On Wed, May 22, 2002 at 02:35:24PM -0700, Mark Mitchell wrote:
> Agreed; still if we're going to talk about threads we have to have some
> model of what a thread is.  Even if we say "you create threads by some
> implementation-defined means", we have to say that a thread is a flow
> of control, that there are no guarantees about the values of
> global variables that are not marked with __thread when accessed
> simultaneously from multiple threads, etc.

Ok, I'll see what I can come up with.

> (I assume that, in C++:
> 
>   __thread const int i = 7;
>   __thread int j = i;
> 
> is OK.  In C++, this would not be a dynamic initialization, if there
> were no __thread modifier, and it seems like you could do this in
> the implementation you're envisioning as well.)

*shrug* So long as the compiler does the constant propagation,
then sure this should be ok.

> I don't see any reason any of them shouldn't
> work, except maybe "section", if there are any restrictions on what
> sections get into the ELF segment in question.

There aren't.  There's a new section flag SHF_TLS that can be
applied to any random section.

> (For example, if you put a __thread variable in the ordinary .data
> section, is that going to work?)

That should fail already because we already disallow variables
to be placed in sections for which there is a flag mismatch.
Thus you can't do

	const int x __attribute__((section("foo"))) = 1;
	int y __attribute__((section("foo"))) = 1;

because X wants FOO to have SHT_WRITE clear, and Y wants
SHF_WRITE set.

I'll add a test for it though, since it's quite a bit more
important here than with read-only vs read-write -- one could
have also taken the position that FOO receives the loosest
read/write/execute bits required for its contents.


r~