Message ID | BANLkTi=Y1fm9Lyj_Xox-EedHqqOg2xvc1A@mail.gmail.com |
---|---|
State | New |
Headers | show |
Uros Bizjak <ubizjak@gmail.com> writes: >> I think I tried something along these lines, but failed with duplicate >> @plt@plt for PIC code. > > Hm, there is no %P1 present, so I don't think this should be an issue. Unfortunately, I do get assembler errors (Sun as at the moment) with your updated patch: libtool: compile: /var/gcc/gcc-4.7.0-20110523/10-gcc/./gcc/xgcc -shared-libgcc -B/var/gcc/gcc-4.7.0-20110523/10-gcc/./gcc -nostdinc++ -L/var/gcc/gcc-4.7.0-20110523/10-gcc/i386-pc-solaris2.10/amd64/libstdc++-v3/src -L/var/gcc/gcc-4.7.0-20110523/10-gcc/i386-pc-solaris2.10/amd64/libstdc++-v3/src/.libs -B/usr/local/i386-pc-solaris2.10/bin/ -B/usr/local/i386-pc-solaris2.10/lib/ -isystem /usr/local/i386-pc-solaris2.10/include -isystem /usr/local/i386-pc-solaris2.10/sys-include -m64 -I/vol/gcc/src/hg/trunk/solaris/libstdc++-v3/../gcc -I/var/gcc/gcc-4.7.0-20110523/10-gcc/i386-pc-solaris2.10/amd64/libstdc++-v3/include/i386-pc-solaris2.10 -I/var/gcc/gcc-4.7.0-20110523/10-gcc/i386-pc-solaris2.10/amd64/libstdc++-v3/include -I/vol/gcc/src/hg/trunk/solaris/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -m64 -c /vol/gcc/src/hg/trunk/solaris/libstdc++-v3/libsupc++/fundamental_type_info.cc -fPIC -DPIC -o funinfo.o damental_type_info.o Assembler: eh_globals.cc "/var/tmp//ccJ1MA8h.s", line 17 : Syntax error Near line: " call __tls_get_addr(%rip)@plt" "/var/tmp//ccJ1MA8h.s", line 38 : Syntax error Near line: " call __tls_get_addr(%rip)@plt" make[9]: *** [eh_globals.lo] Error 1 Which makes me wonder if I should run the gcc.dg/torture/tls-*.c tests with -fPIC, too. >>> is IIRC preferred by Sun assebler. >> >> I've never seen such an issue. > > OK, it is your call... please change @plt to @PLT if desired. I'll keep it at @plt for consistency with the rest. Thanks. Rainer
On Tue, 24 May 2011, Rainer Orth wrote: > Which makes me wonder if I should run the gcc.dg/torture/tls-*.c tests > with -fPIC, too. I think it makes sense to try to provide reasonable coverage of TLS tests with all of -fPIC, -fpic, -fPIE and -fpie.
On Tue, May 24, 2011 at 5:34 PM, Rainer Orth <ro@cebitec.uni-bielefeld.de> wrote: > Uros Bizjak <ubizjak@gmail.com> writes: > >>> I think I tried something along these lines, but failed with duplicate >>> @plt@plt for PIC code. >> >> Hm, there is no %P1 present, so I don't think this should be an issue. > > Unfortunately, I do get assembler errors (Sun as at the moment) with > your updated patch: > > libtool: compile: /var/gcc/gcc-4.7.0-20110523/10-gcc/./gcc/xgcc -shared-libgcc -B/var/gcc/gcc-4.7.0-20110523/10-gcc/./gcc -nostdinc++ -L/var/gcc/gcc-4.7.0-20110523/10-gcc/i386-pc-solaris2.10/amd64/libstdc++-v3/src -L/var/gcc/gcc-4.7.0-20110523/10-gcc/i386-pc-solaris2.10/amd64/libstdc++-v3/src/.libs -B/usr/local/i386-pc-solaris2.10/bin/ -B/usr/local/i386-pc-solaris2.10/lib/ -isystem /usr/local/i386-pc-solaris2.10/include -isystem /usr/local/i386-pc-solaris2.10/sys-include -m64 -I/vol/gcc/src/hg/trunk/solaris/libstdc++-v3/../gcc -I/var/gcc/gcc-4.7.0-20110523/10-gcc/i386-pc-solaris2.10/amd64/libstdc++-v3/include/i386-pc-solaris2.10 -I/var/gcc/gcc-4.7.0-20110523/10-gcc/i386-pc-solaris2.10/amd64/libstdc++-v3/include -I/vol/gcc/src/hg/trunk/solaris/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -m64 -c /vol/gcc/src/hg/trunk/solaris/libstdc++-v3/libsupc++/fundamental_type_info.cc -fPIC -DPIC -o funinfo.o > damental_type_info.o > Assembler: eh_globals.cc > "/var/tmp//ccJ1MA8h.s", line 17 : Syntax error > Near line: " call __tls_get_addr(%rip)@plt" > "/var/tmp//ccJ1MA8h.s", line 38 : Syntax error > Near line: " call __tls_get_addr(%rip)@plt" > make[9]: *** [eh_globals.lo] Error 1 Bah. %P has a special handling that removes (%rip). Are you sure Sun assembler requests @plt in PIC and non-PIC cases? Can we solve this with TARGET_SUN_TLS somehow? Thanks, Uros.
Uros Bizjak <ubizjak@gmail.com> writes: >> Assembler: eh_globals.cc >> "/var/tmp//ccJ1MA8h.s", line 17 : Syntax error >> Near line: " call __tls_get_addr(%rip)@plt" >> "/var/tmp//ccJ1MA8h.s", line 38 : Syntax error >> Near line: " call __tls_get_addr(%rip)@plt" >> make[9]: *** [eh_globals.lo] Error 1 > > Bah. %P has a special handling that removes (%rip). Are you sure Sun > assembler requests @plt in PIC and non-PIC cases? Can we solve this Pretty much so: my first attempts to resolve this consisted in taking the regular gcc assembler output and mangling it until it worked with ld. > with TARGET_SUN_TLS somehow? We could certainly duplicate (some of) the logic that %P already uses, but I though it easier to just introduce a straightforward variant (%p) instead. It's not pretty, but it worked. Rainer
On Tue, May 24, 2011 at 6:42 PM, Rainer Orth <ro@cebitec.uni-bielefeld.de> wrote: > Uros Bizjak <ubizjak@gmail.com> writes: > >>> Assembler: eh_globals.cc >>> "/var/tmp//ccJ1MA8h.s", line 17 : Syntax error >>> Near line: " call __tls_get_addr(%rip)@plt" >>> "/var/tmp//ccJ1MA8h.s", line 38 : Syntax error >>> Near line: " call __tls_get_addr(%rip)@plt" >>> make[9]: *** [eh_globals.lo] Error 1 >> >> Bah. %P has a special handling that removes (%rip). Are you sure Sun >> assembler requests @plt in PIC and non-PIC cases? Can we solve this > > Pretty much so: my first attempts to resolve this consisted in taking > the regular gcc assembler output and mangling it until it worked with ld. > >> with TARGET_SUN_TLS somehow? > > We could certainly duplicate (some of) the logic that %P already uses, > but I though it easier to just introduce a straightforward variant (%p) > instead. It's not pretty, but it worked. OK then... can you propose a new patch, please, changing as little of generic code as possible? Uros.
Uros Bizjak <ubizjak@gmail.com> writes: >> We could certainly duplicate (some of) the logic that %P already uses, >> but I though it easier to just introduce a straightforward variant (%p) >> instead. It's not pretty, but it worked. > > OK then... can you propose a new patch, please, changing as little of > generic code as possible? I'll try, but somewhat fear that I will arive again at what I had initially. Will probably have to wait for the weekend. Rainer
Index: i386.md =================================================================== --- i386.md (revision 174119) +++ i386.md (working copy) @@ -12367,6 +12367,12 @@ { output_asm_insn ("lea{l}\t{%a2@tlsgd(,%1,1), %0|%0, %a2@tlsgd[%1*1]}", operands); + if (TARGET_SUN_TLS) +#ifdef HAVE_AS_IX86_TLSGDPLT + return "call\t%a2@tlsgdplt"; +#else + return "call\t%a3@plt"; +#endif return "call\t%P3"; } [(set_attr "type" "multi") @@ -12397,6 +12403,8 @@ ("lea{q}\t{%a1@tlsgd(%%rip), %%rdi|rdi, %a1@tlsgd[rip]}", operands); fputs (ASM_SHORT "0x6666\n", asm_out_file); fputs ("\trex64\n", asm_out_file); + if (TARGET_SUN_TLS) + return "call\t%a2@plt"; return "call\t%P2"; } [(set_attr "type" "multi") @@ -12424,6 +12432,12 @@ { output_asm_insn ("lea{l}\t{%&@tlsldm(%1), %0|%0, %&@tlsldm[%1]}", operands); + if (TARGET_SUN_TLS) +#ifdef HAVE_AS_IX86_TLSLDMPLT + return "call\t%&@tlsldmplt"; +#else + return "call\t%a2@plt"; +#endif return "call\t%P2"; } [(set_attr "type" "multi") @@ -12450,6 +12464,8 @@ { output_asm_insn ("lea{q}\t{%&@tlsld(%%rip), %%rdi|rdi, %&@tlsld[rip]}", operands); + if (TARGET_SUN_TLS) + return "call\t%a1@plt"; return "call\t%P1"; } [(set_attr "type" "multi")