Message ID | 1288376060-12168-2-git-send-email-andi@firstfloor.org |
---|---|
State | New |
Headers | show |
On Fri, Oct 29, 2010 at 11:14 AM, Andi Kleen <andi@firstfloor.org> wrote: > From: Andi Kleen <ak@linux.intel.com> > > [Updated version, see changelog below. I decided to drop > gcc-ld for now because that one seemed to be problematic > and is only needed for some specific project. I guess I can > keep it separate.] > > Earlier review resulted in a request for having gcc-... wrappers > to handle the LTO symbol tables for ranlib/ar. This is needed for slim > lto files, because these tools cannot read the symbol table > otherwise. Essentially they just call binutils with > the LTO plugin specified. > > Other compilers with LTO support tend to have similar tools. > > This patch implements those wrappers. > > The wrappers are also needed for a LTO slim of gcc. Right now > they have to be manually specified for that. > > The wrappers require uptodate binutils (the upcoming release) > with plugin support enabled. There is currently no autoconf > support to detect that. The wrappers query the gcc driver > in an attempt to handle cross compilation and so naming everywhere > > v2: drop gcc-ld for now. support relocated installation trees. > > gcc/lto/ > > 2010-10-26 Andi Kleen <ak@linux.intel.com> > > * Make-lang.in (AR_INSTALL_NAME, RANLIB_INSTALL_NAME, LTO_WRAPPERS): > Add. > (lto.all.cross, lto.start.cross): Add dependency to LTO_WRAPPERS. > (lto.install.common): Install wrappers. > (lto.mostlyclean): Clean wrappers. > * gcc-ar, gcc-ranlib.in: Add. > > gcc/ > > 2010-10-26 Andi Kleen <ak@linux.intel.com> > > * doc/invoke.texi (gcc-ar, gcc-ranlib): Document. > diff --git a/gcc/lto/gcc-ranlib b/gcc/lto/gcc-ranlib > new file mode 100644 > index 0000000..467d593 > --- /dev/null > +++ b/gcc/lto/gcc-ranlib > @@ -0,0 +1,7 @@ > +#!/bin/sh > +# wrapper for ranlib with GCC LTO support > + > +BASE=`readlink -f $0` > +BINDIR=`dirname $BASE` > +AR=${AR:-`$BINDIR/gcc -print-prog-name=ar`} > +exec $AR -s --plugin `$GCC_BINDIR/gcc -print-lto-plugin` "$@" > -- > 1.7.1 > Did you mean exec $AR -s --plugin `$BINDIR/gcc -print-lto-plugin` "$@" Also does it work in the GCC build directory?
> > exec $AR -s --plugin `$BINDIR/gcc -print-lto-plugin` "$@" Yes you're right of course. Fixed. Weird my test worked. Maybe the variable was already set. > Also does it work in the GCC build directory? Right now for that you have to override AR, it doesn't know about xgcc. Ok I guess it should. Will fix that too. -Andi
On Fri, Oct 29, 2010 at 11:41 AM, Andi Kleen <andi@firstfloor.org> wrote: >> >> exec $AR -s --plugin `$BINDIR/gcc -print-lto-plugin` "$@" > > Yes you're right of course. Fixed. gcc-ranlib have the same problem. Don't we also need "gcc -nm"?
On 10/29/2010 08:14 PM, Andi Kleen wrote: > +ifeq ($(enable_plugin),yes) > + $(INSTALL_SCRIPT) lto/gcc-ar $(DESTDIR)$(bindir)/$(AR_INSTALL_NAME) > + $(INSTALL_SCRIPT) lto/gcc-ranlib $(DESTDIR)$(bindir)/$(RANLIB_INSTALL_NAME) > +endif In addition to what pointed out by Joseph (including the preference for a C implementation), this is also wrong for cross-compiling. It needs to be installed as $(DESTDIR)$(gcc_tooldir)/bin/$(AR_INSTALL_NAME) in that case. >> exec $AR --plugin `$BINDIR/gcc -print-lto-plugin` "$@" quotes around $BINDIR, as Ralf suggested, but also around the backticks and $AR. For portability that needs to be LTOPLUGIN=`"$BINDIR"/gcc -print-lto-plugin` exec "$AR" --plugin "$LTOPLUGIN" "$@" Paolo
On Fri, 29 Oct 2010, Paolo Bonzini wrote: > On 10/29/2010 08:14 PM, Andi Kleen wrote: > > +ifeq ($(enable_plugin),yes) > > + $(INSTALL_SCRIPT) lto/gcc-ar $(DESTDIR)$(bindir)/$(AR_INSTALL_NAME) > > + $(INSTALL_SCRIPT) lto/gcc-ranlib > > $(DESTDIR)$(bindir)/$(RANLIB_INSTALL_NAME) > > +endif > > In addition to what pointed out by Joseph (including the preference for a C > implementation), this is also wrong for cross-compiling. It needs to be > installed as $(DESTDIR)$(gcc_tooldir)/bin/$(AR_INSTALL_NAME) in that case. I thought the point was to install a binary for users to use, not for internal use by other programs - that is, something in bindir, which is the place for user binaries, not gcc_tooldir/bin, which is the place for internal binaries. AR_INSTALL_NAME is the transformed name, suitable for use in bindir. (The copies of "gcc" and "g++" in gcc_tooldir/bin are actually completely useless, as they don't know how to locate the other parts of the installation so fail trying to exec cc1 or cc1plus; the driver is only relocatable as long as it's run from bindir. GNU ld, however, *does* know how to locate its ldscripts directory when run from either location.)
On 10/29/2010 11:51 PM, Joseph S. Myers wrote: > On Fri, 29 Oct 2010, Paolo Bonzini wrote: > >> On 10/29/2010 08:14 PM, Andi Kleen wrote: >>> +ifeq ($(enable_plugin),yes) >>> + $(INSTALL_SCRIPT) lto/gcc-ar $(DESTDIR)$(bindir)/$(AR_INSTALL_NAME) >>> + $(INSTALL_SCRIPT) lto/gcc-ranlib >>> $(DESTDIR)$(bindir)/$(RANLIB_INSTALL_NAME) >>> +endif >> >> In addition to what pointed out by Joseph (including the preference for a C >> implementation), this is also wrong for cross-compiling. It needs to be >> installed as $(DESTDIR)$(gcc_tooldir)/bin/$(AR_INSTALL_NAME) in that case. > > I thought the point was to install a binary for users to use, not for > internal use by other programs - that is, something in bindir, which is > the place for user binaries, not gcc_tooldir/bin, which is the place for > internal binaries. AR_INSTALL_NAME is the transformed name, suitable for > use in bindir. You're right. I was confused by gcc-ar using $BINDIR/gcc to locate gcc (which doesn't work for cross-compiling). Paolo
* Paolo Bonzini wrote on Fri, Oct 29, 2010 at 10:22:50PM CEST: > >>exec $AR --plugin `$BINDIR/gcc -print-lto-plugin` "$@" > > quotes around $BINDIR, as Ralf suggested, but also around the > backticks and $AR. For portability that needs to be > > LTOPLUGIN=`"$BINDIR"/gcc -print-lto-plugin` > exec "$AR" --plugin "$LTOPLUGIN" "$@" JFTR: can $AR be 'ar -X32_64' (on AIX) at this point? Cheers, Ralf
On Sat, Oct 30, 2010 at 08:32:21AM +0200, Ralf Wildenhues wrote: > * Paolo Bonzini wrote on Fri, Oct 29, 2010 at 10:22:50PM CEST: > > >>exec $AR --plugin `$BINDIR/gcc -print-lto-plugin` "$@" > > > > quotes around $BINDIR, as Ralf suggested, but also around the > > backticks and $AR. For portability that needs to be > > > > LTOPLUGIN=`"$BINDIR"/gcc -print-lto-plugin` > > exec "$AR" --plugin "$LTOPLUGIN" "$@" > > JFTR: can $AR be 'ar -X32_64' (on AIX) at this point? Does AIX support binutils and LTO? This all only works with GNU binutils and LTO support anyways. Anyways my trend is to go to shelve the patch (or rather keep the wrappers as a separate package) because the reception has been too negative. I guess it won't be too difficult to download it separately for people who need it. -Andi
On 10/30/2010 09:46 AM, Andi Kleen wrote: > On Sat, Oct 30, 2010 at 08:32:21AM +0200, Ralf Wildenhues wrote: >> * Paolo Bonzini wrote on Fri, Oct 29, 2010 at 10:22:50PM CEST: >>>>> exec $AR --plugin `$BINDIR/gcc -print-lto-plugin` "$@" >>> >>> quotes around $BINDIR, as Ralf suggested, but also around the >>> backticks and $AR. For portability that needs to be >>> >>> LTOPLUGIN=`"$BINDIR"/gcc -print-lto-plugin` >>> exec "$AR" --plugin "$LTOPLUGIN" "$@" >> >> JFTR: can $AR be 'ar -X32_64' (on AIX) at this point? > > Does AIX support binutils and LTO? This all only works with GNU binutils > and LTO support anyways. > > Anyways my trend is to go to shelve the patch (or rather keep > the wrappers as a separate package) because the reception has been too > negative. I guess it won't be too difficult to download it separately > for people who need it. I would still like that patch 1/2 goes in, please. Paolo
> I would still like that patch 1/2 goes in, please.
If someone approves it I can commit it.
-Andi
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index d6784ad..5cae0e4 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -7565,6 +7565,9 @@ be exported, it is possible to combine @option{-flto} and interprocedural optimizers to use more aggressive assumptions which may lead to improved optimization opportunities. +In some cases you may need to use the @command{gcc-ar} and +@command{gcc-ranlib} commands to manage ar files of LTO objects. + 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 2dc6409..56f126d 100644 --- a/gcc/lto/Make-lang.in +++ b/gcc/lto/Make-lang.in @@ -28,16 +28,29 @@ 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)') +RANLIB_INSTALL_NAME := $(shell echo gcc-ranlib|sed '$(program_transform_name)') + +ifeq ($(enable_plugin),yes) +LTO_WRAPPERS = lto/gcc-ar 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) + $(INSTALL_SCRIPT) lto/gcc-ar $(DESTDIR)$(bindir)/$(AR_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 b/gcc/lto/gcc-ar new file mode 100755 index 0000000..4a49e23 --- /dev/null +++ b/gcc/lto/gcc-ar @@ -0,0 +1,7 @@ +#!/bin/sh +# wrapper for ar with GCC LTO support + +BASE=`readlink -f $0` +BINDIR=`dirname $BASE` +AR=${AR:-`$BINDIR/gcc -print-prog-name=ar`} +exec $AR --plugin `$GCC_BINDIR/gcc -print-lto-plugin` "$@" diff --git a/gcc/lto/gcc-ranlib b/gcc/lto/gcc-ranlib new file mode 100644 index 0000000..467d593 --- /dev/null +++ b/gcc/lto/gcc-ranlib @@ -0,0 +1,7 @@ +#!/bin/sh +# wrapper for ranlib with GCC LTO support + +BASE=`readlink -f $0` +BINDIR=`dirname $BASE` +AR=${AR:-`$BINDIR/gcc -print-prog-name=ar`} +exec $AR -s --plugin `$GCC_BINDIR/gcc -print-lto-plugin` "$@"
From: Andi Kleen <ak@linux.intel.com> [Updated version, see changelog below. I decided to drop gcc-ld for now because that one seemed to be problematic and is only needed for some specific project. I guess I can keep it separate.] Earlier review resulted in a request for having gcc-... wrappers to handle the LTO symbol tables for ranlib/ar. This is needed for slim lto files, because these tools cannot read the symbol table otherwise. Essentially they just call binutils with the LTO plugin specified. Other compilers with LTO support tend to have similar tools. This patch implements those wrappers. The wrappers are also needed for a LTO slim of gcc. Right now they have to be manually specified for that. The wrappers require uptodate binutils (the upcoming release) with plugin support enabled. There is currently no autoconf support to detect that. The wrappers query the gcc driver in an attempt to handle cross compilation and so naming everywhere v2: drop gcc-ld for now. support relocated installation trees. gcc/lto/ 2010-10-26 Andi Kleen <ak@linux.intel.com> * Make-lang.in (AR_INSTALL_NAME, RANLIB_INSTALL_NAME, LTO_WRAPPERS): Add. (lto.all.cross, lto.start.cross): Add dependency to LTO_WRAPPERS. (lto.install.common): Install wrappers. (lto.mostlyclean): Clean wrappers. * gcc-ar, gcc-ranlib.in: Add. gcc/ 2010-10-26 Andi Kleen <ak@linux.intel.com> * doc/invoke.texi (gcc-ar, gcc-ranlib): Document. --- gcc/doc/invoke.texi | 3 +++ gcc/lto/Make-lang.in | 17 +++++++++++++++-- gcc/lto/gcc-ar | 7 +++++++ gcc/lto/gcc-ranlib | 7 +++++++ 4 files changed, 32 insertions(+), 2 deletions(-) create mode 100755 gcc/lto/gcc-ar create mode 100644 gcc/lto/gcc-ranlib