multiple defs. of TLS common symbols?

multiple defs. of TLS common symbols?

[Gary Funck]

We use TLS relocated symbols to create thread-local symbols
in the GCC UPC compiler, and have run into an issue illustrated
by the following program, on a test case that defines a
common symbol in several files, and uses it in a single file.

The following program fails to link, with multiple defs:

% head s.c t.c main.c
==> s.c <==
__thread int x;

==> t.c <==
__thread int x;

==> main.c <==
__thread int x;

int main()
{
  x = 1;
}

% gcc s.c t.c main.c
/tmp/ccK5Aj3k.o:(.tbss+0x0): multiple definition of `x'
/tmp/ccm0kY5f.o:(.tbss+0x0): first defined here
/tmp/ccchPiAt.o:(.tbss+0x0): multiple definition of `x'
/tmp/ccm0kY5f.o:(.tbss+0x0): first defined here
collect2: ld returned 1 exit status

But if we don't use TLS storage, it all links just fine:

% gcc -D__thread= s.c t.c main.c

Off-hand this looks like it might be a linker issue, but
perhaps there's an issue with the use of __thread in
in the context above?

Re: multiple defs. of TLS common symbols?

[Ian Lance Taylor]

Gary Funck <gary@intrepid.com> writes:

> We use TLS relocated symbols to create thread-local symbols
> in the GCC UPC compiler, and have run into an issue illustrated
> by the following program, on a test case that defines a
> common symbol in several files, and uses it in a single file.

The only way I know to get a TLS common symbol out of gcc is to use an
omp pragma:

int x;
#pragma omp threadprivate (x)

Otherwise TLS variables are generated as definitions rather than as
common variables.  Personally I tend to think that that is a good
thing.  Treating uninitialized variables as common variables is a
non-standard extension even for C90.  We can't get rid of them for
existing code, but __thread code is by definition new.

Why do you want them to be common?

Ian

Re: multiple defs. of TLS common symbols?

[Gary Funck]

On 01/13/10 17:15:10, Ian Lance Taylor wrote:
[...]
> Otherwise TLS variables are generated as definitions rather than as
> common variables. 
> 
> Why do you want them to be common?

For GCC/UPC compiled programs there are two compilation modes: 1) Each
UPC thread is implemented as a full process, and these processes might
be distributed across a network.  2) Each UPC thread is implemented as
an OS thread (ie, pthread), and they are created by a single process
and execute within its address spec.

In the "process model", "int x;" has the usual semantics.  It is
defined as a common symbol.  In the "pthread model", each file scoped
variable is "localized" and becomes thread local; this is implemented
by defining the variable using TLS relocation.

Intermixing previously compiled C code that refers to file scoped
variables with GCC/UPC compiled "pthread mode" files will likely not
work well.  But if the C code is compiled with the GCC/UPC compiler in
"pthread mode" all file scoped symbols will be localized and everything
should work as expected.

The "process model" is the more natural and preferred way to compile
UPC programs.  The pthread model can offer some efficiencies and can
make it easier to debug the program.

Given the above, the goal of compiling in pthreads mode is to be able
to compile regular "C" code as is, with the same behavior as when it
was compiled in the normal process model.  Thus, we want to translate
all file scoped variables into localized TLS variables with the fewest
surprises and differences.

> Personally I tend to think that that is a good
> thing.  Treating uninitialized variables as common variables is a
> non-standard extension even for C90.  We can't get rid of them for
> existing code, but __thread code is by definition new.

I agree with your statement above, but for our purposes things
will work better if we do create commonized TLS symbols.

Maybe we can use GOMP's method for creating commonized
TLS variables.  Thanks for pointing it out.

Do you/others on this list have a reference that supports
the statement: "Treating uninitialized variables
as common variables is a non-standard extension even for C90."?
(I did see a thread on this list, late April 1999, that
discussed some of the issues, but nothing definitive.)

thanks.

Re: multiple defs. of TLS common symbols?

[Ian Lance Taylor]

Gary Funck <gary@intrepid.com> writes:

> Do you/others on this list have a reference that supports
> the statement: "Treating uninitialized variables
> as common variables is a non-standard extension even for C90."?
> (I did see a thread on this list, late April 1999, that
> discussed some of the issues, but nothing definitive.)

I have a hardcopy of the C90 standard but I can't easily show it to
you.

Online I found this:

    http://www.faqs.org/docs/artu/c_evolution.html

    [T]he ANSI Draft Standard finally settled on definition-reference
    rules in 1988.  Common-block public storage is still admitted as
    an acceptable variation by the standard.

Ian

Re: multiple defs. of TLS common symbols?

[Gary Funck]

On 01/14/10 08:26:31, Ian Lance Taylor wrote:
> Online I found this:
> 
>     http://www.faqs.org/docs/artu/c_evolution.html
> 
>     [T]he ANSI Draft Standard finally settled on definition-reference
>     rules in 1988.  Common-block public storage is still admitted as
>     an acceptable variation by the standard.

Thanks, I found some dicussion in the C99 Rationle document,
http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf
section 6.2.2, "Linkage of Identifiers" (pp. 32-34).

The email thread on this mailing list that I was referring to is here:
http://gcc.gnu.org/ml/gcc/2009-04/msg00812.html