Patchwork Add gcc-ar, gcc-nm, gcc-ranlib

login
register
mail settings
Submitter H.J. Lu
Date Dec. 3, 2010, 1:36 a.m.
Message ID <AANLkTinAr-wpvUkt1XL87Yu8uxGeYv011gwX1Vf7_nQT@mail.gmail.com>
Download mbox | patch
Permalink /patch/74083/
State New
Headers show

Comments

H.J. Lu - Dec. 3, 2010, 1:36 a.m.
On Thu, Dec 2, 2010 at 4:37 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
> 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.
>

Here is the updated patch.

Thanks.

Patch

diff --git a/gcc/configure b/gcc/configure
index e1866a4..442dd58 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -670,6 +670,7 @@  subdirs
 slibdir
 dollar
 gcc_tooldir
+host_lto_plugin_soname
 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,13 @@  $as_echo "#define ENABLE_LTO 1" >>confdefs.h
 
 		    enable_lto=yes
 
+
+		    ac_config_files="$ac_config_files lto/gcc-ar:lto/lto-tools.in"
+
+		    ac_config_files="$ac_config_files lto/gcc-nm:lto/lto-tools.in"
+
+		    ac_config_files="$ac_config_files lto/gcc-ranlib:lto/lto-tools.in"
+
 		    ;;
 		*) ;;
 	esac
@@ -26769,6 +26777,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/lto-tools.in" ;;
+    "lto/gcc-nm") CONFIG_FILES="$CONFIG_FILES lto/gcc-nm:lto/lto-tools.in" ;;
+    "lto/gcc-ranlib") CONFIG_FILES="$CONFIG_FILES lto/gcc-ranlib:lto/lto-tools.in" ;;
     "$all_outputs") CONFIG_FILES="$CONFIG_FILES $all_outputs" ;;
     "default") CONFIG_COMMANDS="$CONFIG_COMMANDS default" ;;
 
@@ -27352,6 +27363,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 lto/gcc-ar ;;
+    "lto/gcc-nm":F) chmod +x lto/gcc-nm ;;
+    "lto/gcc-ranlib":F) chmod +x lto/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..adccce4 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -4474,6 +4474,10 @@  changequote([,])dnl
 		    AC_DEFINE(ENABLE_LTO, 1, [Define to enable LTO support.])
 		    enable_lto=yes
 		    AC_SUBST(enable_lto)
+		    AC_SUBST(host_lto_plugin_soname)
+		    AC_CONFIG_FILES(lto/gcc-ar:lto/lto-tools.in, [chmod +x lto/gcc-ar])
+		    AC_CONFIG_FILES(lto/gcc-nm:lto/lto-tools.in, [chmod +x lto/gcc-nm])
+		    AC_CONFIG_FILES(lto/gcc-ranlib:lto/lto-tools.in, [chmod +x lto/gcc-ranlib])
 		    ;;
 		*) ;;
 	esac
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 94e8160..3a37dc5 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -7610,6 +7610,15 @@  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.  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.
+
 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/lto-tools.in b/gcc/lto/lto-tools.in
new file mode 100644
index 0000000..bcfdc0b
--- /dev/null
+++ b/gcc/lto/lto-tools.in
@@ -0,0 +1,40 @@ 
+#!/bin/sh
+# binutils wrapper with GCC LTO support
+# requires binutils 2.21+
+
+exeext=@host_exeext@
+
+invoked=`basename "$0"`
+BINDIR=`dirname "$0"`
+
+if [ -x "$BINDIR/../xgcc$exeext" ] ; then
+  GCC="$BINDIR/../xgcc$exeext"
+  ARG=-B$BINDIR/../
+else
+  ARG=
+  if [ -x "$BINDIR/gcc" ] ; then
+    GCC="$BINDIR/gcc$exeext"
+  else
+    GCC=gcc$exeext
+  fi
+fi
+
+case "$invoked" in
+  gcc-ar)
+    PROG=ar$exeext
+    PROG_ENV=AR
+    ;;
+  gcc-nm)
+    PROG=nm$exeext
+    PROG_ENV=NM
+    ;;
+  gcc-ranlib)
+    PROG=ranlib$exeext
+    PROG_ENV=RANLIB
+    ;;
+esac
+
+eval prog="\${$PROG_ENV}"
+PROG=${prog:-`"$GCC" -print-prog-name=$PROG`}
+
+exec "$PROG" --plugin `"$GCC" $ARG -print-prog-name="@host_lto_plugin_soname@"` "$@"