This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: externs and thread local storage
- From: "Seongbae Park" <seongbae dot park at gmail dot com>
- To: "Gary Funck" <gary at intrepid dot com>
- Cc: "Gcc Mailing List" <gcc at gcc dot gnu dot org>
- Date: Sun, 2 Jul 2006 03:14:54 -0400
- Subject: Re: externs and thread local storage
- References: <JCEPIPKHCJGDMPOHDOIGKEIFDFAA.gary@intrepid.com>
On 7/1/06, Gary Funck <gary@intrepid.com> wrote:
...
What are the technical reasons for the front-end enforcing this restriction,
when apparently some linkers will handle the TLS linkage fine? If in fact
it is required that __thread be added to the extern, is the compiler simply
accommodating a limitation/bug in the linker?
Because the compiler has to generate different code
for accesses to __thread vs non __thread variable:
# cat -n t.c
1 extern int i1;
2 extern __thread int i2;
3
4 int func1() { return i1; }
5 int func2() { return i2; }
# gcc -O -S t.c
# cat t.s
.file "t.c"
.text
.globl func1
.type func1,@function
func1:
pushl %ebp
movl %esp, %ebp
movl i1, %eax
leave
ret
.Lfe1:
.size func1,.Lfe1-func1
.globl func2
.type func2,@function
func2:
pushl %ebp
movl %esp, %ebp
movl i2@INDNTPOFF, %eax
movl %gs:(%eax), %eax
leave
ret
.Lfe2:
.size func2,.Lfe2-func2
.ident "GCC: (GNU) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)"
#
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";