| Message ID | AANLkTincB7MxS4dFkbcPAVTWHJJmBXwJ-hwd3kJhK6Xp@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
> --- /dev/null > +++ b/gcc/lto/gcc-ar.in > @@ -0,0 +1,18 @@ > +#!/bin/sh > +# wrapper for ar with GCC LTO support > +# requires binutils 2.21+ > + > +BASE=`readlink -f $0` Portable? > +BINDIR=`dirname $BASE` > + > +if [ -x "$BINDIR/xgcc" ] ; then > + GCC=xgcc > + ARG=-B$BINDIR > +else > + GCC=gcc > + ARG= > +fi > + > +AR=${AR:-`"$BINDIR/$GCC" -print-prog-name=ar`} > + > +exec $AR --plugin `$BINDIR/$GCC $ARG -print-prog-name=@LTOPLUGINSONAME@` "$@" Missing quotes around $AR, $BINDIR/$GCC and @LTOPLUGINSONAME@. > +NM=${NM:-`"$BINDIR/$GCC" -print-prog-name=nm`} > + > +exec $NM --plugin `$BINDIR/$GCC $ARG -print-prog-name=@LTOPLUGINSONAME@` "$@" Likewise. > +AR=${AR:-`"$BINDIR/$GCC" -print-prog-name=ar`} > + > +exec $AR -s --plugin `$BINDIR/$GCC $ARG -print-prog-name=@LTOPLUGINSONAME@` "$@" Likewise. Mentions of the script in the docs would need to say that they are scripts and so they are not necessarily available on non-POSIX platforms. Give the amount of duplication, it would probably have been easiest to do in C, I still believe. Paolo
On Thu, Dec 2, 2010 at 3:26 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote: > On 02/12/2010 22:35, H.J. Lu wrote: >> Hi, >> >> Here is the new implementation of gcc-ar, gcc-nm, gcc-ranlib. >> It doesn't require any new gcc option. OK for trunk? > > The documentation isn't very detailed: > >> +In some cases, you may need to use the @command{gcc-ar}, >> +@command{gcc-nm} and @command{gcc-ranlib} commands to manage LTO >> +object files. > > Can it not say at least a little something about in what cases you may need > to use them, and what the difference is between them and the regular binutils? > Any improvements are more than welcome.
On 02/12/2010 22:35, H.J. Lu wrote: > Hi, > > Here is the new implementation of gcc-ar, gcc-nm, gcc-ranlib. > It doesn't require any new gcc option. OK for trunk? The documentation isn't very detailed: > +In some cases, you may need to use the @command{gcc-ar}, > +@command{gcc-nm} and @command{gcc-ranlib} commands to manage LTO > +object files. Can it not say at least a little something about in what cases you may need to use them, and what the difference is between them and the regular binutils? cheers, DaveK
On Thu, Dec 2, 2010 at 3:44 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote: > On 02/12/2010 23:09, H.J. Lu wrote: >> On Thu, Dec 2, 2010 at 3:26 PM, Dave Korn wrote: >>> On 02/12/2010 22:35, H.J. Lu wrote: >>>> Hi, >>>> >>>> Here is the new implementation of gcc-ar, gcc-nm, gcc-ranlib. >>>> It doesn't require any new gcc option. OK for trunk? >>> The documentation isn't very detailed: >>> >>>> +In some cases, you may need to use the @command{gcc-ar}, >>>> +@command{gcc-nm} and @command{gcc-ranlib} commands to manage LTO >>>> +object files. >>> Can it not say at least a little something about in what cases you may need >>> to use them, and what the difference is between them and the regular binutils? >>> >> >> Any improvements are more than welcome. > > I'd happily do so, but I don't know what they're for! > They are used to handle object files with IR: # nm y.o 0000000000000001 C __gnu_lto_v1 0000000000000000 T main U printf U sin U strtol # /export/build/gnu/gcc-lto/release/usr/gcc-4.6.0/bin/gcc-nm y.o 00000000 T main U strtol
On 02/12/2010 23:09, H.J. Lu wrote: > On Thu, Dec 2, 2010 at 3:26 PM, Dave Korn wrote: >> On 02/12/2010 22:35, H.J. Lu wrote: >>> Hi, >>> >>> Here is the new implementation of gcc-ar, gcc-nm, gcc-ranlib. >>> It doesn't require any new gcc option. OK for trunk? >> The documentation isn't very detailed: >> >>> +In some cases, you may need to use the @command{gcc-ar}, >>> +@command{gcc-nm} and @command{gcc-ranlib} commands to manage LTO >>> +object files. >> Can it not say at least a little something about in what cases you may need >> to use them, and what the difference is between them and the regular binutils? >> > > Any improvements are more than welcome. I'd happily do so, but I don't know what they're for! cheers, DaveK
On Thu, Dec 2, 2010 at 4:10 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote: > On 02/12/2010 23:31, H.J. Lu wrote: >> On Thu, Dec 2, 2010 at 3:44 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote: >>> On 02/12/2010 23:09, H.J. Lu wrote: >>>> On Thu, Dec 2, 2010 at 3:26 PM, Dave Korn wrote: >>>>> On 02/12/2010 22:35, H.J. Lu wrote: >>>>>> Hi, >>>>>> >>>>>> Here is the new implementation of gcc-ar, gcc-nm, gcc-ranlib. >>>>>> It doesn't require any new gcc option. OK for trunk? >>>>> The documentation isn't very detailed: >>>>> >>>>>> +In some cases, you may need to use the @command{gcc-ar}, >>>>>> +@command{gcc-nm} and @command{gcc-ranlib} commands to manage LTO >>>>>> +object files. >>>>> Can it not say at least a little something about in what cases you may need >>>>> to use them, and what the difference is between them and the regular binutils? >>>>> >>>> Any improvements are more than welcome. >>> I'd happily do so, but I don't know what they're for! >>> >> >> They are used to handle object files with IR: > > Ah, so the difference is just that they process the LTO symtab, rather than > the native object format symbols? > Yes. But I think gcc-ar and gcc-ranlib only work on IR-only object files,.
On 02/12/2010 23:31, H.J. Lu wrote: > On Thu, Dec 2, 2010 at 3:44 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote: >> On 02/12/2010 23:09, H.J. Lu wrote: >>> On Thu, Dec 2, 2010 at 3:26 PM, Dave Korn wrote: >>>> On 02/12/2010 22:35, H.J. Lu wrote: >>>>> Hi, >>>>> >>>>> Here is the new implementation of gcc-ar, gcc-nm, gcc-ranlib. >>>>> It doesn't require any new gcc option. OK for trunk? >>>> The documentation isn't very detailed: >>>> >>>>> +In some cases, you may need to use the @command{gcc-ar}, >>>>> +@command{gcc-nm} and @command{gcc-ranlib} commands to manage LTO >>>>> +object files. >>>> Can it not say at least a little something about in what cases you may need >>>> to use them, and what the difference is between them and the regular binutils? >>>> >>> Any improvements are more than welcome. >> I'd happily do so, but I don't know what they're for! >> > > They are used to handle object files with IR: Ah, so the difference is just that they process the LTO symtab, rather than the native object format symbols? cheers, DaveK
> Yes. But I think gcc-ar and gcc-ranlib only work on IR-only object files,.
Should work on both actually.
-Andi
On 03/12/2010 00:00, H.J. Lu wrote: > On Thu, Dec 2, 2010 at 4:10 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote: >> On 02/12/2010 23:31, H.J. Lu wrote: >>> On Thu, Dec 2, 2010 at 3:44 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote: >>>> On 02/12/2010 23:09, H.J. Lu wrote: >>>>> On Thu, Dec 2, 2010 at 3:26 PM, Dave Korn wrote: >>>>>> On 02/12/2010 22:35, H.J. Lu wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Here is the new implementation of gcc-ar, gcc-nm, gcc-ranlib. >>>>>>> It doesn't require any new gcc option. OK for trunk? >>>>>> The documentation isn't very detailed: >>>>>> >>>>>>> +In some cases, you may need to use the @command{gcc-ar}, >>>>>>> +@command{gcc-nm} and @command{gcc-ranlib} commands to manage LTO >>>>>>> +object files. >>>>>> Can it not say at least a little something about in what cases you may need >>>>>> to use them, and what the difference is between them and the regular binutils? >>>>>> >>>>> Any improvements are more than welcome. >>>> I'd happily do so, but I don't know what they're for! >>>> >>> They are used to handle object files with IR: >> Ah, so the difference is just that they process the LTO symtab, rather than >> the native object format symbols? >> > > Yes. But I think gcc-ar and gcc-ranlib only work on IR-only object files,. 'k. So, how about something like: In some cases, you may need to use the @command{gcc-ar}, @command{gcc-nm} and @command{gcc-ranlib} commands to manage LTO object files. These are POSIX-compliant shell scripts that operate on the symbol tables contained in the GIMPLE bytecode, rather than on the native format symbols that may be present in an object file. @command{gcc-ar} and @command{gcc-ranlib} can only operate on object files that contain solely GIMPLE bytecode and no native object code; @command{gcc-nm} will simply ignore native object symbols. cheers, DaveK
On 03/12/2010 00:16, Andi Kleen wrote: > >> Yes. But I think gcc-ar and gcc-ranlib only work on IR-only object >> files,. > > Should work on both actually. > Ah, so then please strike the final sentence of my suggested documentation. cheers, DaveK
On Thu, Dec 2, 2010 at 4:16 PM, Andi Kleen <ak@linux.intel.com> wrote: > >> Yes. But I think gcc-ar and gcc-ranlib only work on IR-only object >> files,. > > Should work on both actually. > I got [hjl@gnu-6 pr12245-6]$ /export/build/gnu/gcc-lto/release/usr/gcc-4.6.0/bin/gcc-nm y.o 00000000 T main U strtol [hjl@gnu-6 pr12245-6]$ nm y.o 0000000000000001 C __gnu_lto_v1 0000000000000000 T main U printf U sin U strtol [hjl@gnu-6 pr12245-6]$ /export/build/gnu/gcc-lto/release/usr/gcc-4.6.0/bin/gcc-ar rc liby.a y.o ar: liby.a: Error reading y.o: File truncated [hjl@gnu-6 pr12245-6]$ readelf -S y.o There are 24 section headers, starting at offset 0x9a0: Section Headers: [Nr] Name Type Address Offset Size EntSize Flags Link Info Align [ 0] NULL 0000000000000000 00000000 0000000000000000 0000000000000000 0 0 0 [ 1] .text PROGBITS 0000000000000000 00000040 0000000000000000 0000000000000000 AX 0 0 4 [ 2] .data PROGBITS 0000000000000000 00000040 0000000000000000 0000000000000000 WA 0 0 4 [ 3] .bss NOBITS 0000000000000000 00000040 0000000000000000 0000000000000000 WA 0 0 4 [ 4] .gnu.lto_.jmpfunc PROGBITS 0000000000000000 00000040 0000000000000056 0000000000000000 0 0 1 [ 5] .gnu.lto_.purecon PROGBITS 0000000000000000 00000096 0000000000000013 0000000000000000 0 0 1 [ 6] .gnu.lto_main.6f4 PROGBITS 0000000000000000 000000a9 000000000000020b 0000000000000000 0 0 1 [ 7] .gnu.lto_.cgraph. PROGBITS 0000000000000000 000002b4 0000000000000047 0000000000000000 0 0 1 [ 8] .gnu.lto_.vars.6f PROGBITS 0000000000000000 000002fb 0000000000000012 0000000000000000 0 0 1 [ 9] .gnu.lto_.refs.6f PROGBITS 0000000000000000 0000030d 0000000000000012 0000000000000000 0 0 1 [10] .gnu.lto_.statics PROGBITS 0000000000000000 0000031f 0000000000000014 0000000000000000 0 0 1 [11] .gnu.lto_.decls.6 PROGBITS 0000000000000000 00000333 00000000000003fd 0000000000000000 0 0 1 [12] .gnu.lto_.symtab. PROGBITS 0000000000000000 00000730 000000000000002a 0000000000000000 0 0 1 [13] .gnu.lto_.opts PROGBITS 0000000000000000 0000075a 0000000000000038 0000000000000000 0 0 1 [14] .rodata.str1.1 PROGBITS 0000000000000000 00000792 0000000000000004 0000000000000001 AMS 0 0 1 [15] .text.startup PROGBITS 0000000000000000 000007a0 0000000000000033 0000000000000000 AX 0 0 16 [16] .rela.text.startu RELA 0000000000000000 00001228 0000000000000060 0000000000000018 22 15 8 [17] .comment PROGBITS 0000000000000000 000007d3 000000000000002a 0000000000000001 MS 0 0 1 [18] .note.GNU-stack PROGBITS 0000000000000000 000007fd 0000000000000000 0000000000000000 0 0 1 [19] .eh_frame PROGBITS 0000000000000000 00000800 0000000000000030 0000000000000000 A 0 0 8 [20] .rela.eh_frame RELA 0000000000000000 00001288 0000000000000018 0000000000000018 22 19 8 [21] .shstrtab STRTAB 0000000000000000 00000830 000000000000016d 0000000000000000 0 0 1 [22] .symtab SYMTAB 0000000000000000 00000fa0 0000000000000258 0000000000000018 23 20 8 [23] .strtab STRTAB 0000000000000000 000011f8 0000000000000029 0000000000000000 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings), l (large) I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) [hjl@gnu-6 pr12245-6]$
On Thu, 2 Dec 2010, H.J. Lu wrote: > Hi, > > Here is the new implementation of gcc-ar, gcc-nm, gcc-ranlib. > It doesn't require any new gcc option. OK for trunk? It is rather rude to submit a patch that ignores previous feedback without referencing the previous discussion and detailing what you are ignoring and why. There are multiple problems that I previously pointed out that have not been addressed in the patch - this is not limited to the point that the programs should be implemented in C.
On Thu, Dec 2, 2010 at 5:44 PM, Joseph S. Myers <joseph@codesourcery.com> wrote: > On Thu, 2 Dec 2010, H.J. Lu wrote: > >> Hi, >> >> Here is the new implementation of gcc-ar, gcc-nm, gcc-ranlib. >> It doesn't require any new gcc option. OK for trunk? > > It is rather rude to submit a patch that ignores previous feedback without > referencing the previous discussion and detailing what you are ignoring > and why. There are multiple problems that I previously pointed out that > have not been addressed in the patch - this is not limited to the point > that the programs should be implemented in C. > Consider this patch is withdrawn.
diff --git a/gcc/configure b/gcc/configure index e1866a4..1e8519c 100755 --- a/gcc/configure +++ b/gcc/configure @@ -670,6 +670,7 @@ subdirs slibdir dollar gcc_tooldir +LTOPLUGINSONAME enable_lto MAINT zlibinc @@ -17286,7 +17287,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<_LT_EOF -#line 17289 "configure" +#line 17290 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -17392,7 +17393,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<_LT_EOF -#line 17395 "configure" +#line 17396 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -25691,6 +25692,14 @@ $as_echo "#define ENABLE_LTO 1" >>confdefs.h enable_lto=yes + LTOPLUGINSONAME="${host_lto_plugin_soname}" + + ac_config_files="$ac_config_files lto/gcc-ar:lto/gcc-ar.in" + + ac_config_files="$ac_config_files lto/gcc-nm:lto/gcc-nm.in" + + ac_config_files="$ac_config_files lto/gcc-ranlib:lto/gcc-ranlib.in" + ;; *) ;; esac @@ -26769,6 +26778,9 @@ do "as") CONFIG_FILES="$CONFIG_FILES as:exec-tool.in" ;; "collect-ld") CONFIG_FILES="$CONFIG_FILES collect-ld:exec-tool.in" ;; "nm") CONFIG_FILES="$CONFIG_FILES nm:exec-tool.in" ;; + "lto/gcc-ar") CONFIG_FILES="$CONFIG_FILES lto/gcc-ar:lto/gcc-ar.in" ;; + "lto/gcc-nm") CONFIG_FILES="$CONFIG_FILES lto/gcc-nm:lto/gcc-nm.in" ;; + "lto/gcc-ranlib") CONFIG_FILES="$CONFIG_FILES lto/gcc-ranlib:lto/gcc-ranlib.in" ;; "$all_outputs") CONFIG_FILES="$CONFIG_FILES $all_outputs" ;; "default") CONFIG_COMMANDS="$CONFIG_COMMANDS default" ;; @@ -27352,6 +27364,9 @@ $as_echo "$as_me: executing $ac_file commands" >&6;} "as":F) chmod +x as ;; "collect-ld":F) chmod +x collect-ld ;; "nm":F) chmod +x nm ;; + "lto/gcc-ar":F) chmod +x gcc-ar ;; + "lto/gcc-nm":F) chmod +x gcc-nm ;; + "lto/gcc-ranlib":F) chmod +x gcc-ranlib ;; "default":C) case ${CONFIG_HEADERS} in *auto-host.h:config.in*) diff --git a/gcc/configure.ac b/gcc/configure.ac index dace19c..8516134 100644 --- a/gcc/configure.ac +++ b/gcc/configure.ac @@ -4474,6 +4474,11 @@ changequote([,])dnl AC_DEFINE(ENABLE_LTO, 1, [Define to enable LTO support.]) enable_lto=yes AC_SUBST(enable_lto) + LTOPLUGINSONAME="${host_lto_plugin_soname}" + AC_SUBST(LTOPLUGINSONAME) + AC_CONFIG_FILES(lto/gcc-ar:lto/gcc-ar.in, [chmod +x gcc-ar]) + AC_CONFIG_FILES(lto/gcc-nm:lto/gcc-nm.in, [chmod +x gcc-nm]) + AC_CONFIG_FILES(lto/gcc-ranlib:lto/gcc-ranlib.in, [chmod +x gcc-ranlib]) ;; *) ;; esac diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index 94e8160..5fe4bd8 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -7610,6 +7610,10 @@ lead to improved optimization opportunities. Use of @option{-fwhole-program} is not needed when linker plugin is active (see @option{-fuse-linker-plugin}). +In some cases, you may need to use the @command{gcc-ar}, +@command{gcc-nm} and @command{gcc-ranlib} commands to manage LTO +object files. + Regarding portability: the current implementation of LTO makes no attempt at generating bytecode that can be ported between different types of hosts. The bytecode files are versioned and there is a diff --git a/gcc/lto/Make-lang.in b/gcc/lto/Make-lang.in index 16b0f35..ae448b0 100644 --- a/gcc/lto/Make-lang.in +++ b/gcc/lto/Make-lang.in @@ -28,16 +28,32 @@ LTO_H = lto/lto.h $(HASHTAB_H) LINKER_PLUGIN_API_H = $(srcdir)/../include/plugin-api.h LTO_TREE_H = lto/lto-tree.h $(LINKER_PLUGIN_API_H) +AR_INSTALL_NAME := $(shell echo gcc-ar|sed '$(program_transform_name)') +NM_INSTALL_NAME := $(shell echo gcc-nm|sed '$(program_transform_name)') +RANLIB_INSTALL_NAME := $(shell echo gcc-ranlib|sed '$(program_transform_name)') + +ifeq ($(enable_plugin),yes) +LTO_WRAPPERS = lto/gcc-ar lto/gcc-nm lto/gcc-ranlib +else +LTO_WRAPPERS = +endif # Rules # These hooks are used by the main GCC Makefile. Consult that # Makefile for documentation. -lto.all.cross: $(LTO_EXE) -lto.start.encap: $(LTO_EXE) +lto.all.cross: $(LTO_EXE) $(LTO_WRAPPERS) +lto.start.encap: $(LTO_EXE) $(LTO_WRAPPERS) lto.rest.encap: lto.tags: lto.install-common: +ifeq ($(enable_plugin),yes) + $(mkinstalldirs) $(DESTDIR)$(bindir) + $(INSTALL_SCRIPT) lto/gcc-ar $(DESTDIR)$(bindir)/$(AR_INSTALL_NAME) + $(INSTALL_SCRIPT) lto/gcc-nm $(DESTDIR)$(bindir)/$(NM_INSTALL_NAME) + $(INSTALL_SCRIPT) lto/gcc-ranlib $(DESTDIR)$(bindir)/$(RANLIB_INSTALL_NAME) +endif + lto.install-man: lto.install-info: lto.dvi: diff --git a/gcc/lto/gcc-ar.in b/gcc/lto/gcc-ar.in new file mode 100644 index 0000000..79bdf79 --- /dev/null +++ b/gcc/lto/gcc-ar.in @@ -0,0 +1,18 @@ +#!/bin/sh +# wrapper for ar with GCC LTO support +# requires binutils 2.21+ + +BASE=`readlink -f $0` +BINDIR=`dirname $BASE` + +if [ -x "$BINDIR/xgcc" ] ; then + GCC=xgcc + ARG=-B$BINDIR +else + GCC=gcc + ARG= +fi + +AR=${AR:-`"$BINDIR/$GCC" -print-prog-name=ar`} + +exec $AR --plugin `$BINDIR/$GCC $ARG -print-prog-name=@LTOPLUGINSONAME@` "$@" diff --git a/gcc/lto/gcc-nm.in b/gcc/lto/gcc-nm.in new file mode 100644 index 0000000..25ebffd --- /dev/null +++ b/gcc/lto/gcc-nm.in @@ -0,0 +1,18 @@ +#!/bin/sh +# wrapper for ar with GCC LTO support +# requires binutils 2.21+ + +BASE=`readlink -f $0` +BINDIR=`dirname $BASE` + +if [ -x "$BINDIR/xgcc" ] ; then + GCC=xgcc + ARG=-B$BINDIR +else + GCC=gcc + ARG= +fi + +NM=${NM:-`"$BINDIR/$GCC" -print-prog-name=nm`} + +exec $NM --plugin `$BINDIR/$GCC $ARG -print-prog-name=@LTOPLUGINSONAME@` "$@" diff --git a/gcc/lto/gcc-ranlib.in b/gcc/lto/gcc-ranlib.in new file mode 100644 index 0000000..b6c6d8f --- /dev/null +++ b/gcc/lto/gcc-ranlib.in @@ -0,0 +1,18 @@ +#!/bin/sh +# wrapper for ranlib with GCC LTO support +# requires binutils 2.21+ + +BASE=`readlink -f $0` +BINDIR=`dirname $BASE` + +if [ -x "$BINDIR/xgcc" ] ; then + GCC=xgcc + ARG=-B$BINDIR +else + GCC=gcc + ARG= +fi + +AR=${AR:-`"$BINDIR/$GCC" -print-prog-name=ar`} + +exec $AR -s --plugin `$BINDIR/$GCC $ARG -print-prog-name=@LTOPLUGINSONAME@` "$@"