Closed Quuxplusone closed 6 years ago
Quuxplusone
commented
16 years ago | Bugzilla Link | PR2137 |
| Status | RESOLVED FIXED |
| Importance | P normal |
| Reported by | Török Edwin (edwin+bugs@etorok.eu) |
| Reported on | 2008-03-11 08:07:32 -0700 |
| Last modified on | 2018-11-07 00:22:26 -0800 |
| Version | unspecified |
| Hardware | PC Linux |
| CC | anton@korobeynikov.info, llvm-bugs@lists.llvm.org |
| Fixed by commit(s) | |
| Attachments | |
| Blocks | |
| Blocked by | |
| See also |
Quuxplusone
commented
16 years ago Is this x86-32 or x86-64 build?
Quuxplusone
commented
16 years ago (In reply to comment #1)
> Is this x86-32 or x86-64 build?
>
My glibc build test is x86-32.Ok. Looks like some weirdness in PIC handling mixed with TLS stuff.
1. What if you disable threads?
2. Could you please provide some reduction?(In reply to comment #3)
> Ok. Looks like some weirdness in PIC handling mixed with TLS stuff.
>
> 1. What if you disable threads?
I am trying that now.
> 2. Could you please provide some reduction?
>
Ok, the problem is in resolv/res_libc.c itself.
Here is a reduced testcase (the order of #define, use of _res, etc. matters!):
struct __res_state{int id};
# define attribute_hidden __attribute__ ((visibility ("hidden")))
#define _res (*__resp)
#define __resp __libc_resp
# define attribute_tls_model_ie __attribute__ ((tls_model ("initial-exec")))
extern __thread struct __res_state *__resp attribute_tls_model_ie;
int foo()
{
_res.id=0;
}
int bar()
{
_res.id=1;
}
#undef _res
struct __res_state _res __attribute__((section (".bss")));
#undef __resp
__thread struct __res_state *__resp = &_res;
extern __thread struct __res_state *__libc_resp
__attribute__ ((alias ("__resp"))) attribute_hidden;
Compile as llvm-gcc -fPIC -c foo.c -o foo.o && readelf -a foo.o
Here is what llvm generates:
Relocation section '.rel.text' at offset 0x3d0 contains 4 entries:
Offset Info Type Sym.Value Sym. Name
0000000d 0000070a R_386_GOTPC 00000000 _GLOBAL_OFFSET_TABLE_
00000013 00000803 R_386_GOT32 00000000 __libc_resp
0000003d 0000070a R_386_GOTPC 00000000 _GLOBAL_OFFSET_TABLE_
00000043 00000803 R_386_GOT32 00000000 __libc_resp
Here is what gcc generates:
00000004 00000b02 R_386_PC32 00000000 __i686.get_pc_thunk.cx
0000000a 00000c0a R_386_GOTPC 00000000 _GLOBAL_OFFSET_TABLE_
00000010 00000d10 R_386_TLS_GOTIE 00000000 __libc_resp
00000023 00000b02 R_386_PC32 00000000 __i686.get_pc_thunk.cx
00000029 00000c0a R_386_GOTPC 00000000 _GLOBAL_OFFSET_TABLE_
0000002f 00000d10 R_386_TLS_GOTIE 00000000 __libc_resp(In reply to comment #4)
> (In reply to comment #3)
> > Ok. Looks like some weirdness in PIC handling mixed with TLS stuff.
> >
> > 1. What if you disable threads?
>
> I am trying that now.
>
There is a semi-random code generator crash (when building with thread
support), see #2138, but on an entirely different file.
I am not sure if building without threads is even possible. I tried --without-
__thread, disable nptl, disable tls (--without-tls), --disable-sanity-checks,
yet it still wants to compile libc-tls.c (and it fails because I disabled
threads).
If I tell it to use linuxthreads instead of nptl it fails with some missing
headers.Ok. It seems some extra care should be added to codegen with PIC+TLS
Quuxplusone
commented
16 years ago Actually, two problems here:
1. Alias should be printed as hidden
2. Aliasee is thread local, but alias is definitely not. Extra care should be
added in this case.Fixed in:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080310/059590.html
Testcase here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080310/059591.html
Current TLS implementation for PIC is far from ideal, but hope the stuff will
work.
PS: This is really nasty alias usage :)(In reply to comment #8)
> Fixed in:
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-
20080310/059590.html
>
> Testcase here:
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-
20080310/059591.html
>
> Current TLS implementation for PIC is far from ideal, but hope the stuff will
> work.
Thanks, I no longer get this linker error
>
> PS: This is really nasty alias usage :)
>
There are more nasty linking problems in glibc-2.7/csu/, opening a new bug.