On Thu, Nov 29, 2012 at 1:10 AM, Markus Trippelsdorf <mar...@trippelsdorf.de> wrote: > On 2012.11.29 at 09:43 +0100, Richard Biener wrote: >> On Thu, Nov 29, 2012 at 5:18 AM, H.J. Lu <hjl.to...@gmail.com> wrote: >> > From: "H.J. Lu" <hjl.to...@gmail.com> >> > To: gcc-patches@gcc.gnu.org >> > Cc: Joseph Myers <jos...@codesourcery.com>, Paolo Bonzini >> > <bonz...@gnu.org> >> > Bcc: >> > Subject: [PATCH] Support -fuse-ld=bfd and -fuse-ld=gold >> > Reply-To: >> > >> > Hi, >> > >> > Binutils supports 2 linkers, ld.gold and ld.bfd. One of them is >> > configured as the default linker, ld, which is used by GCC. Sometimes, >> > we want to use the alternate linker with GCC at run-time. This patch >> > adds -fuse-ld=bfd and -fuse-ld=gold options to GCC driver. It changes >> > collect2.c to pick either ld.bfd or ld.gold. It also adds >> > ORIGINAL_LD_BFD_FOR_TARGET and ORIGINAL_LD_GOLD_FOR_TARGET to >> > exec-tool.in to add -fuse-ld=bfd and -fuse-ld=gold support to >> > collect-ld. Since ld.bfd nor ld.gold know the new options, you >> > will get >> > >> > # ./xgcc -B./ /tmp/x.c -fuse-ld=gold -v >> > ... >> > ./collect-ld --eh-frame-hdr -m elf_x86_64 -dynamic-linker >> > /lib64/ld-linux-x86-64.so.2 -fuse-ld=gold /lib/../lib64/crt1.o >> > /lib/../lib64/crti.o ./crtbegin.o -L. -L/lib/../lib64 -L/usr/lib/../lib64 >> > /tmp/cclVWcGz.o -v -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc >> > --as-needed -lgcc_s --no-as-needed ./crtend.o /lib/../lib64/crtn.o >> > GNU gold (Linux/GNU Binutils 2.23.51.0.7.20121127) 1.11 >> > /usr/local/bin/ld.gold: fatal error: -f/--auxiliary may not be used >> > without -shared >> > collect2: error: ld returned 1 exit status >> > >> > This is because we pass everything to ld and ld.bfd/ld.gold doesn't >> > understand -fuse-ld=bfd/-fuse-ld=gold. It isn't a problem for collect2 >> > since it will filter-out -fuse-ld=bfd/-fuse-ld=gold. I will submit a >> > binutils patch to ignore -fuse-ld=bfd/-fuse-ld=gold, similar to -flto >> > options. >> > >> > OK to install? >> >> Do we need to consider GNU ld and gold coming from different binutils >> versions >> and thus do we need two sets of linker feature tests at configure >> time? Eventually >> also if GNU ld and gold are not in feature-parity for the same binutils >> version?
This is no different from run-time linker vs configure-time linker. If it is a link-time failure, we can check: [hjl@gnu-6 tmp]$ gcc x.o -v -Wl,-v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.7.2/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --disable-build-with-cxx --disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --with-multilib-list=m32,m64,mx32 --build=x86_64-redhat-linux Thread model: posix gcc version 4.7.2 20120921 (Red Hat 4.7.2-2) (GCC) COMPILER_PATH=/usr/libexec/gcc/x86_64-redhat-linux/4.7.2/:/usr/libexec/gcc/x86_64-redhat-linux/4.7.2/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/4.7.2/:/usr/lib/gcc/x86_64-redhat-linux/ LIBRARY_PATH=/usr/lib/gcc/x86_64-redhat-linux/4.7.2/:/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64' /usr/libexec/gcc/x86_64-redhat-linux/4.7.2/collect2 --build-id --no-add-needed --eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/4.7.2/crtbegin.o -L/usr/lib/gcc/x86_64-redhat-linux/4.7.2 -L/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../.. x.o -v -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-redhat-linux/4.7.2/crtend.o /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/crtn.o collect2 version 4.7.2 20120921 (Red Hat 4.7.2-2) /usr/local/bin/ld --build-id --no-add-needed --eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/4.7.2/crtbegin.o -L/usr/lib/gcc/x86_64-redhat-linux/4.7.2 -L/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../.. x.o -v -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-redhat-linux/4.7.2/crtend.o /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/crtn.o GNU ld (GNU Binutils) 2.23.51.20121128 [hjl@gnu-6 tmp]$ >> That is, isn't this going to create hard to debug issues for users? User uses it by choice. You can check which linker is used. > Additionally, what is the rationale for this patch? IOW why isn't the > following > enough? > > x4 ~ # ln -f /usr/x86_64-pc-linux-gnu/binutils-bin/git/ld.gold > /usr/x86_64-pc-linux-gnu/binutils-bin/git/ld > x4 ~ # ld -v > GNU gold (GNU Binutils 2.23.51.20121126) 1.11 > x4 ~ # ln -f /usr/x86_64-pc-linux-gnu/binutils-bin/git/ld.bfd > /usr/x86_64-pc-linux-gnu/binutils-bin/git/ld > x4 ~ # ld -v > GNU ld (GNU Binutils) 2.23.51.20121126 > > Or is this meant as a temporary workaround hack for gold bugs? > Yes, it is used as a temporary workaround for linker bugs. --- H.J.