RFA/RFC: Enable both gold and ld in a single toolchain

classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|

RFA/RFC: Enable both gold and ld in a single toolchain

Nick Clifton
Hi Guys,

  I have created a patch (attached) that enables both GOLD and LD to be
  built and used in a single toolchain.  This allows easy comparison of
  the two linkers with just a single command line switch to choose
  between them.

  I suspect that the patch may not be approved, but I wanted to
  contribute it in case anyone else was interested in this facility.

  In order to build both linkers it is necessary to run the top level
  configure script with the switch:

    --enable-gold=both

  Then once the linkers are built/installed you can add:

    -Luse-gold

  to a gcc command line to use the GOLD linker.  Otherwise the LD linker
  (aka gld) will be used.

  There is one special caveat though.  When installing the two linkers
  it is necessary to install gold before ld as otherwise the ld linker
  will be overwritten.  Ie run:

    make ... install-gold install-ld ...


  The choice of -Luse-gold as the switch to select the gold linker is a
  hack.  One of the requirements for programs and scripts that sit
  between gcc and the linker, (such as collect2 and collect-ld), is that
  gcc must continue to work if they are not there and the linker is
  invoked directly.  Thus any options that are intended for the
  intermediate programs/scripts must be disguised in some fashion.
 
  Collect2 uses environment variables to get its options but this is,
  IMHO, heinous.  So instead I chose to use the -L switch.  This can
  take an arbitrary text argument and it will not cause the linker to
  complain if the argument is not recognised or the so called library
  search path does not actually exist.  In theory it could break a link
  if there really is a sub-directory of the current directory called
  "use-gold" and this directory contains subtly invalid binaries, but
  this is very unlikely to happen.

  Comments welcome, and if the gcc maintainers feel that this feature is
  actually wanted in the mainstream sources I will happy to apply my
  patch and maintain it in the future.

  Tested with i686-pc-linux-gnu, sparc-elf and arm-eabi toolchains, and
  an x86 bootstrap.  (That is bootstrapping without gold enabled, just
  to make sure that I did not break anything).

Cheers
  Nick

./ChangeLog
2010-03-04  Nick Clifton  <[hidden email]>

        * configure.ac (--enable-gold): Accept a value of "both".  If
        this value is given then configure both ld and gold.
        * configure: Regenerate.

gcc/ChangeLog
2010-03-04  Nick Clifton  <[hidden email]>

        * configure.ac (gcc_cv_gold_srcdir): New cached variable -
        contains the location of the gold sources.
        (ORIGINAL_GOLD_FOR_TARGET): New substituted variable - contains
        the name of the locally built gold executable.
        * configure: Regenerate.
        * collect2.c (main): Detect the -Luse-gold switch and select the
        gold linker, if found.
        * exec-tool.in: Detect the -Luse-gold switch and select the gold
        linker, if found.  Add support for -v switch.  Report problems
        locating linker executable.

gold/ChangeLog
2010-03-04  Nick Clifton  <[hidden email]>

        * Makefile.am (install-exec-local): Also install the executable
        as a binary named 'gold'.
        * Makefile.in: Regenerate.


Index: gold/Makefile.am
===================================================================
RCS file: /cvs/src/src/gold/Makefile.am,v
retrieving revision 1.60
diff -c -3 -p -r1.60 Makefile.am
*** gold/Makefile.am 3 Feb 2010 05:36:55 -0000 1.60
--- gold/Makefile.am 4 Mar 2010 15:08:22 -0000
*************** install-exec-local: ld-new$(EXEEXT)
*** 185,190 ****
--- 185,197 ----
   ln $(DESTDIR)$(bindir)/$${n}$(EXEEXT) $(DESTDIR)$(tooldir)/bin/ld$(EXEEXT) >/dev/null 2>/dev/null \
     || $(INSTALL_PROGRAM) ld-new$(EXEEXT) $(DESTDIR)$(tooldir)/bin/ld$(EXEEXT); \
  fi
+ n=`echo gold | sed '$(transform)'`; \
+ $(INSTALL_PROGRAM) ld-new$(EXEEXT) $(DESTDIR)$(bindir)/$${n}$(EXEEXT); \
+ if test "$(bindir)" != "$(tooldir)/bin"; then \
+  rm -f $(DESTDIR)$(tooldir)/bin/gold$(EXEEXT); \
+  ln $(DESTDIR)$(bindir)/$${n}$(EXEEXT) $(DESTDIR)$(tooldir)/bin/gold$(EXEEXT) >/dev/null 2>/dev/null \
+    || $(INSTALL_PROGRAM) ld-new$(EXEEXT) $(DESTDIR)$(tooldir)/bin/gold$(EXEEXT); \
+ fi
 
  # We want install to imply install-info as per GNU standards, despite
  # the cygnus option.
Index: configure.ac
===================================================================
--- configure.ac (revision 157226)
+++ configure.ac (working copy)
@@ -320,7 +320,7 @@
 [  --enable-gold           use gold instead of ld],
 ENABLE_GOLD=$enableval,
 ENABLE_GOLD=no)
-if test "${ENABLE_GOLD}" = "yes"; then
+if test "${ENABLE_GOLD}" = "yes" -o "${ENABLE_GOLD}" = "both"; then
   # Check for ELF target.
   is_elf=no
   case "${target}" in
@@ -340,7 +340,11 @@
     # Check for target supported by gold.
     case "${target}" in
       i?86-*-* | x86_64-*-* | sparc*-*-* | powerpc*-*-* | arm*-*-*)
-        configdirs="`echo " ${configdirs} " | sed -e 's/ ld / gold /'`"
+        if test "${ENABLE_GOLD}" = "both"; then
+          configdirs="${configdirs} gold"
+ else
+          configdirs="`echo " ${configdirs} " | sed -e 's/ ld / gold /'`"
+ fi
         ;;
     esac
   fi
@@ -2653,7 +2657,9 @@
 esac
 
 case "$enable_bootstrap:$ENABLE_GOLD: $configdirs :,$stage1_languages," in
+  yes:both:*\ gold\ *:*,c++,* | \
   yes:yes:*\ gold\ *:*,c++,*) ;;
+  yes:both:*\ gold\ *:* | \
   yes:yes:*\ gold\ *:*)
     AC_MSG_ERROR([in a combined tree, bootstrapping with --enable-gold requires c++ in stage1_languages])
     ;;
Index: gcc/configure.ac
===================================================================
--- gcc/configure.ac (revision 157226)
+++ gcc/configure.ac (working copy)
@@ -1923,6 +1923,17 @@
         AC_PATH_PROG(gcc_cv_ld, $LD_FOR_TARGET)
 fi])
 
+gcc_cv_ld_gold_srcdir=`echo $srcdir | sed -e 's,/gcc$,,'`/gold
+
+AS_VAR_SET_IF(gcc_cv_gold,, [
+if test -f $gcc_cv_ld_gold_srcdir/configure.ac \
+     && test -f ../gold/Makefile \
+     && test x$build = x$host; then
+ gcc_cv_gold=../gold/ld-new$build_exeext
+else
+        gcc_cv_gold=''
+fi])
+
 ORIGINAL_PLUGIN_LD_FOR_TARGET=$gcc_cv_ld
 PLUGIN_LD=`basename $gcc_cv_ld`
 AC_ARG_WITH(plugin-ld,
@@ -1941,6 +1952,9 @@
   *) AC_CONFIG_FILES(collect-ld:exec-tool.in, [chmod +x collect-ld]) ;;
 esac
 
+ORIGINAL_GOLD_FOR_TARGET=$gcc_cv_gold
+AC_SUBST(ORIGINAL_GOLD_FOR_TARGET)
+
 AC_MSG_CHECKING(what linker to use)
 if test "$gcc_cv_ld" = ../ld/ld-new$build_exeext; then
  # Single tree build which includes ld.  We want to prefer it
Index: gcc/exec-tool.in
===================================================================
--- gcc/exec-tool.in (revision 157226)
+++ gcc/exec-tool.in (working copy)
@@ -21,11 +21,13 @@
 
 ORIGINAL_AS_FOR_TARGET="@ORIGINAL_AS_FOR_TARGET@"
 ORIGINAL_LD_FOR_TARGET="@ORIGINAL_LD_FOR_TARGET@"
+ORIGINAL_GOLD_FOR_TARGET="@ORIGINAL_GOLD_FOR_TARGET@"
 ORIGINAL_PLUGIN_LD_FOR_TARGET="@ORIGINAL_PLUGIN_LD_FOR_TARGET@"
 ORIGINAL_NM_FOR_TARGET="@ORIGINAL_NM_FOR_TARGET@"
 exeext=@host_exeext@
 fast_install=@enable_fast_install@
 objdir=@objdir@
+version="1.1"
 
 invoked=`basename "$0"`
 case "$invoked" in
@@ -35,15 +37,47 @@
     dir=gas
     ;;
   collect-ld)
-    # when using a linker plugin, gcc will always pass '-plugin' as the
-    # first option to the linker.
-    if test x"$1" = "x-plugin"; then
-      original=$ORIGINAL_PLUGIN_LD_FOR_TARGET
-    else
-      original=$ORIGINAL_LD_FOR_TARGET
+    prog=ld-new$exeext
+    # Look for the magic library paths "-Luse-gold" and
+    # "-Luse-ld".  If present then select the indicated
+    # linker.  Otherwise if -plugin is specified then
+    # choose a plugin-capable linker, otherwise use the
+    # default.
+    case "${1+$@} " in
+      *-Luse-gold\ *)
+        original=$ORIGINAL_GOLD_FOR_TARGET
+ dir=gold
+        ;;
+      *-Luse-ld\ *)
+        original=$ORIGINAL_LD_FOR_TARGET
+        dir=ld
+        ;;
+      *-plugin\ *)
+        original=$ORIGINAL_PLUGIN_LD_FOR_TARGET
+        dir=ld
+ ;;
+      *)
+        original=$ORIGINAL_LD_FOR_TARGET
+        dir=ld
+ ;;
+    esac
+
+    # If the selected linker has not been configured then
+    # try using the others, in the order PLUGIN-LD, LD, GOLD.
+    if test x"$original" == x; then
+      if test x"$ORIGINAL_PLUGIN_LD_FOR_TARGET" != x; then
+        original=$ORIGINAL_PLUGIN_LD_FOR_TARGET
+        dir=ld
+      elif test x"$ORIGINAL_LD_FOR_TARGET" != x; then
+        original=$ORIGINAL_LD_FOR_TARGET
+        dir=ld
+      elif test x"$ORIGINAL_GOLD_FOR_TARGET" != x; then
+        original=$ORIGINAL_GOLD_FOR_TARGET
+        dir=gold
+      # Otherwise do nothing - the case statement below
+      # will issue an error message for us.
+      fi
     fi
-    prog=ld-new$exeext
-    dir=ld
     ;;
   nm)
     original=$ORIGINAL_NM_FOR_TARGET
@@ -52,36 +86,65 @@
     ;;
 esac
 
-case "$original" in
-  ../*)
-    # compute absolute path of the location of this script
+case x"$original" in
+  x../*)
+    # Compute absolute path to the location of this script.
     tdir=`dirname "$0"`
     scriptdir=`cd "$tdir" && pwd`
 
     if test -x $scriptdir/../$dir/$prog; then
-      test "$fast_install" = yes || exec $scriptdir/../$dir/$prog ${1+"$@"}
+      if test "$fast_install" = yes; then
+        # If libtool did everything it needs to do, there's a fast path.
+        lt_prog=$scriptdir/../$dir/$objdir/lt-$prog
 
-      # if libtool did everything it needs to do, there's a fast path
-      lt_prog=$scriptdir/../$dir/$objdir/lt-$prog
-      test -x $lt_prog && exec $lt_prog ${1+"$@"}
-
-      # libtool has not relinked ld-new yet, but we cannot just use the
-      # previous stage (because then the relinking would just never happen!).
-      # So we take extra care to use prev-ld/ld-new *on recursive calls*.
-      test x"$LT_RCU" = x"1" && exec $scriptdir/../prev-$dir/$prog ${1+"$@"}
-
-      LT_RCU=1; export LT_RCU
-      $scriptdir/../$dir/$prog ${1+"$@"}
-      result=$?
-      exit $result
-
+ if test -x $lt_prog; then
+  original=$lt_prog
+        else
+          # Libtool has not relinked ld-new yet, but we cannot just use the
+          # previous stage (because then the relinking would just never happen!).
+          # So we take extra care to use prev-ld/ld-new *on recursive calls*.
+          if test x"$LT_RCU" = x"1"; then
+    original=$scriptdir/../prev-$dir/$prog
+          else
+            LT_RCU=1; export LT_RCU
+            case "${1+$@} " in
+              *-v\ *)
+               echo "$invoked version $version"
+               echo $scriptdir/../$dir/$prog ${1+"$@"}
+               ;;
+            esac
+            $scriptdir/../$dir/$prog ${1+"$@"}
+            result=$?
+            exit $result
+          fi
+        fi
+      else
+ original=$scriptdir/../$dir/$prog
+      fi
     else
-      exec $scriptdir/../prev-$dir/$prog ${1+"$@"}
+      original=$scriptdir/../prev-$dir/$prog
     fi
     ;;
-  *)
-    exec "$original" ${1+"$@"}
+  x)
+    echo "$invoked: executable not configured"
+    exit -1
     ;;
 esac
 
+# If -v has been used then display our version number
+# and then echo the command we are about to invoke.
+case "${1+$@} " in
+  *-v\ *)
+    echo "$invoked version $version"
+    echo $original ${1+"$@"}
+    ;;
+esac
 
+if test -x $original; then
+  exec "$original" ${1+"$@"}
+else
+  echo "$invoked: unable to locate executable: $original"
+  exit -1
+fi
+
+
Index: gcc/collect2.c
===================================================================
--- gcc/collect2.c (revision 157226)
+++ gcc/collect2.c (working copy)
@@ -1111,6 +1111,7 @@
 main (int argc, char **argv)
 {
   static const char *const ld_suffix = "ld";
+  static const char *const gold_suffix  = "gold";
   static const char *const plugin_ld_suffix = PLUGIN_LD;
   static const char *const real_ld_suffix = "real-ld";
   static const char *const collect_ld_suffix = "collect-ld";
@@ -1130,6 +1131,8 @@
 
   const char *const full_ld_suffix =
     concat(target_machine, "-", ld_suffix, NULL);
+  const char *const full_gold_suffix =
+    concat (target_machine, "-", gold_suffix, NULL);
   const char *const full_plugin_ld_suffix =
     concat(target_machine, "-", plugin_ld_suffix, NULL);
   const char *const full_nm_suffix =
@@ -1146,6 +1149,7 @@
     concat (target_machine, "-", gstrip_suffix, NULL);
 #else
   const char *const full_ld_suffix = ld_suffix;
+  const char *const full_gold_suffix = gold_suffix;
   const char *const full_plugin_ld_suffix = plugin_ld_suffix;
   const char *const full_nm_suffix = nm_suffix;
   const char *const full_gnm_suffix = gnm_suffix;
@@ -1168,6 +1172,7 @@
   char **ld1_argv;
   const char **ld1;
   bool use_plugin = false;
+  bool use_gold = false;
 
   /* The kinds of symbols we will have to consider when scanning the
      outcome of a first pass link.  This is ALL to start with, then might
@@ -1256,6 +1261,8 @@
     use_verbose = true;
     lto_mode = LTO_MODE_NONE;
   }
+ else if (! strcmp (argv[i], "-Luse-gold"))
+  use_gold = true;
 #ifdef COLLECT_EXPORT_LIST
  /* since -brtl, -bexport, -b64 are not position dependent
    also check for them here */
@@ -1356,6 +1363,8 @@
     ld_file_name = find_a_file (&cpath,
  use_plugin
  ? plugin_ld_suffix
+ : use_gold
+ ? gold_suffix
  : ld_suffix);
   /* Search the ordinary system bin directories
      for `ld' (if native linking) or `TARGET-ld' (if cross).  */
@@ -1363,6 +1372,8 @@
     ld_file_name = find_a_file (&path,
  use_plugin
  ? full_plugin_ld_suffix
+ : use_gold
+ ? full_gold_suffix
  : full_ld_suffix);
 
 #ifdef REAL_NM_FILE_NAME
Reply | Threaded
Open this post in threaded view
|

Re: RFA/RFC: Enable both gold and ld in a single toolchain

H.J. Lu-30
On Thu, Mar 4, 2010 at 11:21 AM, Nick Clifton <[hidden email]> wrote:

> Hi Guys,
>
>  I have created a patch (attached) that enables both GOLD and LD to be
>  built and used in a single toolchain.  This allows easy comparison of
>  the two linkers with just a single command line switch to choose
>  between them.
>
>  I suspect that the patch may not be approved, but I wanted to
>  contribute it in case anyone else was interested in this facility.
>
>  In order to build both linkers it is necessary to run the top level
>  configure script with the switch:
>
>    --enable-gold=both
>
>  Then once the linkers are built/installed you can add:
>
>    -Luse-gold
>
>  to a gcc command line to use the GOLD linker.  Otherwise the LD linker
>  (aka gld) will be used.
>
>  There is one special caveat though.  When installing the two linkers
>  it is necessary to install gold before ld as otherwise the ld linker
>  will be overwritten.  Ie run:
>
>    make ... install-gold install-ld ...
>
>
>  The choice of -Luse-gold as the switch to select the gold linker is a
>  hack.  One of the requirements for programs and scripts that sit
>  between gcc and the linker, (such as collect2 and collect-ld), is that
>  gcc must continue to work if they are not there and the linker is
>  invoked directly.  Thus any options that are intended for the
>  intermediate programs/scripts must be disguised in some fashion.
>
>  Collect2 uses environment variables to get its options but this is,
>  IMHO, heinous.  So instead I chose to use the -L switch.  This can
>  take an arbitrary text argument and it will not cause the linker to
>  complain if the argument is not recognised or the so called library
>  search path does not actually exist.  In theory it could break a link
>  if there really is a sub-directory of the current directory called
>  "use-gold" and this directory contains subtly invalid binaries, but
>  this is very unlikely to happen.
>
>  Comments welcome, and if the gcc maintainers feel that this feature is
>  actually wanted in the mainstream sources I will happy to apply my
>  patch and maintain it in the future.
>
>  Tested with i686-pc-linux-gnu, sparc-elf and arm-eabi toolchains, and
>  an x86 bootstrap.  (That is bootstrapping without gold enabled, just
>  to make sure that I did not break anything).
>
> Cheers
>  Nick
>
> ./ChangeLog
> 2010-03-04  Nick Clifton  <[hidden email]>
>
>        * configure.ac (--enable-gold): Accept a value of "both".  If
>        this value is given then configure both ld and gold.
>        * configure: Regenerate.
>
> gcc/ChangeLog
> 2010-03-04  Nick Clifton  <[hidden email]>
>
>        * configure.ac (gcc_cv_gold_srcdir): New cached variable -
>        contains the location of the gold sources.
>        (ORIGINAL_GOLD_FOR_TARGET): New substituted variable - contains
>        the name of the locally built gold executable.
>        * configure: Regenerate.
>        * collect2.c (main): Detect the -Luse-gold switch and select the
>        gold linker, if found.
>        * exec-tool.in: Detect the -Luse-gold switch and select the gold
>        linker, if found.  Add support for -v switch.  Report problems
>        locating linker executable.
>
> gold/ChangeLog
> 2010-03-04  Nick Clifton  <[hidden email]>
>
>        * Makefile.am (install-exec-local): Also install the executable
>        as a binary named 'gold'.
>        * Makefile.in: Regenerate.
>
>

Here is another approach to enable both ld and gold:

http://sourceware.org/ml/binutils/2010-01/msg00275.html

It will install both linkers, as ld.bfd and ld.gold, and allow to choose
either ld.bfd or ld.gold as the default linker. Is that possible to
combine your approach with mine?

Thanks.


--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: RFA/RFC: Enable both gold and ld in a single toolchain

Ralf Wildenhues
In reply to this post by Nick Clifton
Hello Nick,

just curious, what does your patch offer over H.J.'s patch?

A few nits:

* Nick Clifton wrote on Thu, Mar 04, 2010 at 08:21:45PM CET:
>   In order to build both linkers it is necessary to run the top level
>   configure script with the switch:
>
>     --enable-gold=both
>
>   Then once the linkers are built/installed you can add:
>
>     -Luse-gold

FWIW, I don't consider abusing existing APIs like this to be a good
idea.  Collect2 is something GCC controls, so you can adjust it; that
doesn't justify in-band signaling in user APIs if you ask me.

BTW, installation order requirements can (and should IMVHO) be
formalized in the toplevel Makefile.def, so parallel make does not fail.

> --- configure.ac (revision 157226)
> +++ configure.ac (working copy)
> @@ -320,7 +320,7 @@
>  [  --enable-gold           use gold instead of ld],
>  ENABLE_GOLD=$enableval,
>  ENABLE_GOLD=no)
> -if test "${ENABLE_GOLD}" = "yes"; then
> +if test "${ENABLE_GOLD}" = "yes" -o "${ENABLE_GOLD}" = "both"; then

test -o is not POSIX, please use test || test instead.

> --- gcc/exec-tool.in (revision 157226)
> +++ gcc/exec-tool.in (working copy)

> @@ -35,15 +37,47 @@
>      dir=gas
>      ;;
>    collect-ld)
> -    # when using a linker plugin, gcc will always pass '-plugin' as the
> -    # first option to the linker.
> -    if test x"$1" = "x-plugin"; then
> -      original=$ORIGINAL_PLUGIN_LD_FOR_TARGET
> -    else
> -      original=$ORIGINAL_LD_FOR_TARGET
> +    prog=ld-new$exeext
> +    # Look for the magic library paths "-Luse-gold" and
> +    # "-Luse-ld".  If present then select the indicated
> +    # linker.  Otherwise if -plugin is specified then
> +    # choose a plugin-capable linker, otherwise use the
> +    # default.
> +    case "${1+$@} " in

${1+$@} is only necessary in places where zero arguments need to be
detected as such, and it is only correct if the quotes are around the $@
alone.  In a case statement, plain $* is sufficient (and more portable):
      case " $* " in ...

but I would usually prefer iterating over the positional parameters:
      for arg
      do
        case $arg in
          -plugin) ...
          ;;
        esac
      done

> +      *-Luse-gold\ *)

Without leading space, this also matches unrelated arguments that only
happen to end in this string.

> +        original=$ORIGINAL_GOLD_FOR_TARGET
> + dir=gold
> +        ;;
[...]

> +    # If the selected linker has not been configured then
> +    # try using the others, in the order PLUGIN-LD, LD, GOLD.
> +    if test x"$original" == x; then

test == is a bashism, = is portable.

> @@ -52,36 +86,65 @@
>      ;;
>  esac
>  
> -case "$original" in
> -  ../*)
> -    # compute absolute path of the location of this script
> +case x"$original" in

Why that x here?  The x used in "test" is to avoid leading hyphens
to let old test programs confuse them with options like -f.  This is not
needed for case.

> +  x../*)
> +    # Compute absolute path to the location of this script.
>      tdir=`dirname "$0"`
>      scriptdir=`cd "$tdir" && pwd`
>  
>      if test -x $scriptdir/../$dir/$prog; then
> -      test "$fast_install" = yes || exec $scriptdir/../$dir/$prog ${1+"$@"}
> +      if test "$fast_install" = yes; then
> +        # If libtool did everything it needs to do, there's a fast path.
> +        lt_prog=$scriptdir/../$dir/$objdir/lt-$prog
>  
> -      # if libtool did everything it needs to do, there's a fast path
> -      lt_prog=$scriptdir/../$dir/$objdir/lt-$prog
> -      test -x $lt_prog && exec $lt_prog ${1+"$@"}
> -
> -      # libtool has not relinked ld-new yet, but we cannot just use the
> -      # previous stage (because then the relinking would just never happen!).
> -      # So we take extra care to use prev-ld/ld-new *on recursive calls*.
> -      test x"$LT_RCU" = x"1" && exec $scriptdir/../prev-$dir/$prog ${1+"$@"}
> -
> -      LT_RCU=1; export LT_RCU
> -      $scriptdir/../$dir/$prog ${1+"$@"}
> -      result=$?
> -      exit $result
> -
> + if test -x $lt_prog; then
> +  original=$lt_prog
> +        else
> +          # Libtool has not relinked ld-new yet, but we cannot just use the
> +          # previous stage (because then the relinking would just never happen!).
> +          # So we take extra care to use prev-ld/ld-new *on recursive calls*.
> +          if test x"$LT_RCU" = x"1"; then
> +    original=$scriptdir/../prev-$dir/$prog
> +          else
> +            LT_RCU=1; export LT_RCU
> +            case "${1+$@} " in
> +              *-v\ *)

See above.

> +               echo "$invoked version $version"

This is not a GCS-compatible version output.

> +               echo $scriptdir/../$dir/$prog ${1+"$@"}
> +               ;;
> +            esac
> +            $scriptdir/../$dir/$prog ${1+"$@"}
> +            result=$?
> +            exit $result
> +          fi
> +        fi
> +      else
> + original=$scriptdir/../$dir/$prog
> +      fi
>      else
> -      exec $scriptdir/../prev-$dir/$prog ${1+"$@"}
> +      original=$scriptdir/../prev-$dir/$prog
>      fi
>      ;;
> -  *)
> -    exec "$original" ${1+"$@"}
> +  x)
> +    echo "$invoked: executable not configured"
> +    exit -1

I don't know whether -1 is portable for shell exit.

>      ;;
>  esac
>  
> +# If -v has been used then display our version number
> +# and then echo the command we are about to invoke.
> +case "${1+$@} " in
> +  *-v\ *)

See above.

> +    echo "$invoked version $version"
> +    echo $original ${1+"$@"}
> +    ;;
> +esac
>  
> +if test -x $original; then
> +  exec "$original" ${1+"$@"}
> +else
> +  echo "$invoked: unable to locate executable: $original"
> +  exit -1
> +fi

Cheers,
Ralf
Reply | Threaded
Open this post in threaded view
|

Re: RFA/RFC: Enable both gold and ld in a single toolchain

Andreas Schwab-4
In reply to this post by Nick Clifton
Ralf Wildenhues <[hidden email]> writes:

>> @@ -52,36 +86,65 @@
>>      ;;
>>  esac
>>  
>> -case "$original" in
>> -  ../*)
>> -    # compute absolute path of the location of this script
>> +case x"$original" in
>
> Why that x here?  The x used in "test" is to avoid leading hyphens
> to let old test programs confuse them with options like -f.  This is not
> needed for case.

And you don't even need the quotes.

>> +  x)
>> +    echo "$invoked: executable not configured"
>> +    exit -1
>
> I don't know whether -1 is portable for shell exit.

POSIX only knows about 0-255 anyway.

Andreas.

--
Andreas Schwab, [hidden email]
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
"And now for something completely different."
Reply | Threaded
Open this post in threaded view
|

Re: RFA/RFC: Enable both gold and ld in a single toolchain

Nick Clifton
In reply to this post by H.J. Lu-30
Hi Guys,

   Thanks very much for the feedback on my original patch.  Attached
below is a revised version in which I have tried to take into account
all of the suggestions that were made.

   H.J. - I apologise for forgetting that you had already submitted a
patch that does basically the same thing as my patch.  I have adopted
most of the ideas from your patch into this revised version, but with a
few changes:

   * I named the BFD based linker "gld" rather than "ld.bfd".  I thought
that this was more intuitive, and it also matches how the linker is
referred in various bits of documentation.

   * I made the --enable-gold=both still have the original linker (gld)
as the default rather than gold.  My reasoning here was that if a
toolchain builder wants to have both linkers then they are going to want
to compare them and they would expect to start with the already
established linker, rather than the new one.  Configuring with
--enable-gold=both/gold will make gold the default linker.


Other changes in this version of the patch include:

   * I have added a dependency to Makefile.def so that gold will be
installed before ld if both exist in the build tree.

   * "test ... -o ..." has been replaced by "test ... || test ..." and
"test ... == ..." by "test ... = ...".

   * I am still matching command line switches using regular
expressions, since I think that it is neater, but the testing should be
more efficient now and less prone to false positives.

   * I have removed the x prefix when checking the original linker path.

   * The output from the --version option now conforms to the GCD.

   * I use "exit 1" as an error return rather than "exit -1".

Apart from that the patch is the same as before.  I have retested it
with a full bootstrap and it still is OK.

So - (finger's crossed) - is the patch OK to apply ?

Cheers
   Nick


gold-and-ld.patch.2 (43K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFA/RFC: Enable both gold and ld in a single toolchain

Matthias Klose-6
On 09.03.2010 10:28, Nick Clifton wrote:

> Hi Guys,
>
> Thanks very much for the feedback on my original patch. Attached below
> is a revised version in which I have tried to take into account all of
> the suggestions that were made.
>
> H.J. - I apologise for forgetting that you had already submitted a patch
> that does basically the same thing as my patch. I have adopted most of
> the ideas from your patch into this revised version, but with a few
> changes:
>
> * I named the BFD based linker "gld" rather than "ld.bfd". I thought
> that this was more intuitive, and it also matches how the linker is
> referred in various bits of documentation.

please don't. the gld name is already used in the binary namespace (although
it's in /usr/sbin).
http://packages.debian.org/search?searchon=contents&keywords=gld&mode=path&suite=unstable&arch=any

Not sure how many distributions already did use H.J's patch, but at least Debian
and Ubuntu will keep these names from this patch for the next release.

   Matthias
Reply | Threaded
Open this post in threaded view
|

Re: RFA/RFC: Enable both gold and ld in a single toolchain

H.J. Lu-30
In reply to this post by Nick Clifton
On Tue, Mar 9, 2010 at 1:28 AM, Nick Clifton <[hidden email]> wrote:

> Hi Guys,
>
>  Thanks very much for the feedback on my original patch.  Attached below is
> a revised version in which I have tried to take into account all of the
> suggestions that were made.
>
>  H.J. - I apologise for forgetting that you had already submitted a patch
> that does basically the same thing as my patch.  I have adopted most of the
> ideas from your patch into this revised version, but with a few changes:
>

I really don't like "-Luse-gold"/"-Luse-ld". It is asking for trouble. What if
I have a library called `libuse-gold.so"? Why can't we add a real new
option? Also gold may be installed as `ld'.  How about -muse-gold/use-gld
or -muse-ld.gold/-muse-ld.bfd?


--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: RFA/RFC: Enable both gold and ld in a single toolchain

Richard Biener
On Tue, Mar 9, 2010 at 3:00 PM, H.J. Lu <[hidden email]> wrote:

> On Tue, Mar 9, 2010 at 1:28 AM, Nick Clifton <[hidden email]> wrote:
>> Hi Guys,
>>
>>  Thanks very much for the feedback on my original patch.  Attached below is
>> a revised version in which I have tried to take into account all of the
>> suggestions that were made.
>>
>>  H.J. - I apologise for forgetting that you had already submitted a patch
>> that does basically the same thing as my patch.  I have adopted most of the
>> ideas from your patch into this revised version, but with a few changes:
>>
>
> I really don't like "-Luse-gold"/"-Luse-ld". It is asking for trouble. What if
> I have a library called `libuse-gold.so"? Why can't we add a real new
> option? Also gold may be installed as `ld'.  How about -muse-gold/use-gld
> or -muse-ld.gold/-muse-ld.bfd?

-fuse-linker-plugin and --with-plugin-ld works just fine for me.

Richard.

>
> --
> H.J.
>
Reply | Threaded
Open this post in threaded view
|

Re: RFA/RFC: Enable both gold and ld in a single toolchain

Paolo Bonzini-2
In reply to this post by Nick Clifton
On 03/04/2010 08:21 PM, Nick Clifton wrote:
> When installing the two linkers
>    it is necessary to install gold before ld as otherwise the ld linker
>    will be overwritten.  Ie run:
>
>      make ... install-gold install-ld ...

Adding this to Makefile.def:

dependencies = { module=install-ld; on=install-gold; };

should make it (dependencies are not "hard" by default).

Paolo
Reply | Threaded
Open this post in threaded view
|

Re: RFA/RFC: Enable both gold and ld in a single toolchain

Ryan Hill-3
In reply to this post by Matthias Klose-6
On Tue, 09 Mar 2010 11:09:07 +0100
Matthias Klose <[hidden email]> wrote:

> Not sure how many distributions already did use H.J's patch, but at least Debian
> and Ubuntu will keep these names from this patch for the next release.

We do and we've changed our build system 3 times now because every second
release renamed everything. It'd be nice to settle on something soon.


--
fonts,                                            by design, by neglect
gcc-porting,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFA/RFC: Enable both gold and ld in a single toolchain

Nick Clifton
Hi Guys,

   OK - I have revised the patch yet again.  This version uses H.J.'s
name for the bfd based linker (ld.bfd) and changes the switches that
selects between gold and ld.bfd to be -fuse-gold and -fuse-ld (or
-fuse-ld.bfd).

   x86 bootstrapping is still OK.

   Any more suggestions or comments ?

Cheers
   Nick

./ChangeLog
2010-03-04  Nick Clifton  <[hidden email]>

        * configure.ac (--enable-gold): Accept a parameter of "both",
         "both/gold" or "both/ld".  If any of these values are given
         then configure both ld and gold.
         * configure: Regenerate.

gcc/ChangeLog
2010-03-04  Nick Clifton  <[hidden email]>

        * configure.ac (gcc_cv_gold_srcdir): New cached variable -
        contains the location of the gold sources.
         (ORIGINAL_GOLD_FOR_TARGET): New substituted variable - contains
        the name of the locally built gold executable.
         * configure: Regenerate.
         * collect2.c (main): Detect the -use-gold and -use-ld switches
        and select the appropriate linker, if found.
         * exec-tool.in: Detect the -use-gold and -use-ld switches and
         select the appropriate linker, if found.
        Add support for -v switch.
        Report problems locating linker executable.
        * gcc.c (LINK_COMMAND_SPEC): Translate -fuse-gold into
        -use-gold and -fuse-ld into -use-ld.
        * common.opt: Add fuse-gold, fuse-ld and fuse-ld.bfd
        * opts.c (comman_handle_option): Ignore -fuse-gold, -fuse-ld
         and -fuse-ld.bfd.
        * doc/invoke.texi: Document the new options.

gold/ChangeLog
2010-03-04  Nick Clifton  <[hidden email]>

        * configure.ac (install_as_default): Define and set to false
        unless --enable-gold or --enable-gold=both/gold has been
        specified.
        * configure: Regenerate.
        * Makefile.am (install-exec-local): Install the executable as
        "gold".  If install_as_default is true then also install it as
        "ld".
         * Makefile.in: Regenerate.

ld/ChangeLog
2010-03-04  Nick Clifton  <[hidden email]>

        * configure.in (install_as_default): Define and set to true
        unless --enable-gold=both/gold has been specified.
        * configure: Regenerate.
        * Makefile.am (transform): Use ld.bfd as the default name of
        the linker.
        (install-exec-local): Also install the executable as a binary
        named 'ld' if install_as_default is true.
        * Makefile.in: Regenerate.

gold-and-ld.patch.3 (24K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFA/RFC: Enable both gold and ld in a single toolchain

H.J. Lu-30
On Thu, Mar 11, 2010 at 6:45 AM, Nick Clifton <[hidden email]> wrote:
> Hi Guys,
>
>  OK - I have revised the patch yet again.  This version uses H.J.'s name for
> the bfd based linker (ld.bfd) and changes the switches that selects between
> gold and ld.bfd to be -fuse-gold and -fuse-ld (or -fuse-ld.bfd).

-fuse-ld is misleading. ld may be gold.  How about "-fuse-ld=[gold|bfd]" which
is consistent with linker names and configure options.


H.J.
---
Reply | Threaded
Open this post in threaded view
|

Re: RFA/RFC: Enable both gold and ld in a single toolchain

Nick Clifton
Hi H.J.

> -fuse-ld is misleading. ld may be gold.  How about "-fuse-ld=[gold|bfd]" which
> is consistent with linker names and configure options.

A good point.  I have attached a revised patch with the option named as
you suggest.  I also omitted to include your name and Roland's in the
ChangeLog entries, so I have updated those as well.

Any other issues with the patch ?

Cheers
   Nick

./ChangeLog
2010-01-05  Roland McGrath  <[hidden email]>
            H.J. Lu  <[hidden email]>

        * configure.ac (--enable-gold): Support both, both/gold and
        both/bfd to add gold to configdirs without removing ld.
        * configure: Regenerated.

gold/ChangeLog
2010-01-05  H.J. Lu  <[hidden email]>
            Nick Clifton  <[hidden email]>

        * configure.ac (install_as_default): Define and set to false
        unless --enable-gold or --enable-gold=both/gold has been
        specified.
        * configure: Regenerate.
        * Makefile.am (install-exec-local): Install the executable as
        "gold".  If install_as_default is true then also install it as
        "ld".
        * Makefile.in: Regenerated.

ld/ChangeLog
2010-01-05  H.J. Lu  <[hidden email]>
            Nick Clifton  <[hidden email]>

        * configure.in (install_as_default): Define and set to true
        unless --enable-gold=both/gold has been specified.
        * configure: Regenerate.
        * Makefile.am (transform): Use ld.bfd as the default name of
        the linker.
        (install-exec-local): Also install the executable as a binary
        named 'ld' if install_as_default is true.
        * Makefile.in: Regenerate.

gcc/ChangeLog
2010-03-04  Nick Clifton  <[hidden email]>

        * configure.ac (gcc_cv_gold_srcdir): New cached variable -
        contains the location of the gold sources.
         (ORIGINAL_GOLD_FOR_TARGET): New substituted variable - contains
        the name of the locally built gold executable.
         * configure: Regenerate.
         * collect2.c (main): Detect the -use-gold and -use-ld switches
        and select the appropriate linker, if found.
         * exec-tool.in: Detect the -use-gold and -use-ld switches and
         select the appropriate linker, if found.
        Add support for -v switch.
        Report problems locating linker executable.
        * gcc.c (LINK_COMMAND_SPEC): Translate -fuse-ld=gold into
        -use-gold and -fuse-ld=bfd into -use-ld.
        * common.opt: Add fuse-ld=gold and fuse-ld=bfd.
        * opts.c (comman_handle_option): Ignore -fuse-ld=gold and
        -fuse-ld=bfd.
        * doc/invoke.texi: Document the new options.

gold-and-ld.patch.4 (26K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFA/RFC: Enable both gold and ld in a single toolchain

H.J. Lu-30
On Tue, Mar 16, 2010 at 10:25 AM, Nick Clifton <[hidden email]> wrote:

> Hi H.J.
>
>> -fuse-ld is misleading. ld may be gold.  How about "-fuse-ld=[gold|bfd]"
>> which
>> is consistent with linker names and configure options.
>
> A good point.  I have attached a revised patch with the option named as you
> suggest.  I also omitted to include your name and Roland's in the ChangeLog
> entries, so I have updated those as well.
>
> Any other issues with the patch ?
>
> Cheers
>  Nick
>
> ./ChangeLog
> 2010-01-05  Roland McGrath  <[hidden email]>
>            H.J. Lu  <[hidden email]>
>
>        * configure.ac (--enable-gold): Support both, both/gold and
>        both/bfd to add gold to configdirs without removing ld.
>        * configure: Regenerated.
>
> gold/ChangeLog
> 2010-01-05  H.J. Lu  <[hidden email]>
>            Nick Clifton  <[hidden email]>
>
>        * configure.ac (install_as_default): Define and set to false
>        unless --enable-gold or --enable-gold=both/gold has been
>        specified.
>        * configure: Regenerate.
>        * Makefile.am (install-exec-local): Install the executable as
>        "gold".  If install_as_default is true then also install it as
>        "ld".
>        * Makefile.in: Regenerated.
>
> ld/ChangeLog
> 2010-01-05  H.J. Lu  <[hidden email]>
>            Nick Clifton  <[hidden email]>
>
>        * configure.in (install_as_default): Define and set to true
>        unless --enable-gold=both/gold has been specified.
>        * configure: Regenerate.
>        * Makefile.am (transform): Use ld.bfd as the default name of
>        the linker.
>        (install-exec-local): Also install the executable as a binary
>        named 'ld' if install_as_default is true.
>        * Makefile.in: Regenerate.
>
> gcc/ChangeLog
> 2010-03-04  Nick Clifton  <[hidden email]>
>
>        * configure.ac (gcc_cv_gold_srcdir): New cached variable -
>        contains the location of the gold sources.
>        (ORIGINAL_GOLD_FOR_TARGET): New substituted variable - contains
>        the name of the locally built gold executable.
>        * configure: Regenerate.
>        * collect2.c (main): Detect the -use-gold and -use-ld switches
>        and select the appropriate linker, if found.
>        * exec-tool.in: Detect the -use-gold and -use-ld switches and
>        select the appropriate linker, if found.
>        Add support for -v switch.
>        Report problems locating linker executable.
>        * gcc.c (LINK_COMMAND_SPEC): Translate -fuse-ld=gold into
>        -use-gold and -fuse-ld=bfd into -use-ld.
>        * common.opt: Add fuse-ld=gold and fuse-ld=bfd.
>        * opts.c (comman_handle_option): Ignore -fuse-ld=gold and
>        -fuse-ld=bfd.
>        * doc/invoke.texi: Document the new options.
>

Is that possible to pass -fuse-ld=XXX directly collect2 so that you
don't need to change exec-tool.in?


--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: RFA/RFC: Enable both gold and ld in a single toolchain

Nick Clifton
Hi H.J.

> Is that possible to pass -fuse-ld=XXX directly to collect2

Sure, but ...

> so that you don't need to change exec-tool.in?

exec-tool will still need to be updated.  It is still invoked (as
"collect-ld") and it still needs to be able to understand the
-use-gold/-use-ld options.

Cheers
   Nick



Reply | Threaded
Open this post in threaded view
|

Re: RFA/RFC: Enable both gold and ld in a single toolchain

H.J. Lu-30
On Tue, Mar 16, 2010 at 10:49 AM, Nick Clifton <[hidden email]> wrote:

> Hi H.J.
>
>> Is that possible to pass -fuse-ld=XXX directly to collect2
>
> Sure, but ...
>
>> so that you don't need to change exec-tool.in?
>
> exec-tool will still need to be updated.  It is still invoked (as
> "collect-ld") and it still needs to be able to understand the
> -use-gold/-use-ld options.
>

Aren't they passed to collect2 directly with "${1+"$@"}"?


--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: RFA/RFC: Enable both gold and ld in a single toolchain

Vladimir Simonov-2
In reply to this post by Nick Clifton
On 03/16/2010 08:49 PM, Nick Clifton wrote:

> Hi H.J.
>
>> Is that possible to pass -fuse-ld=XXX directly to collect2
>
> Sure, but ...
>
>> so that you don't need to change exec-tool.in?
>
> exec-tool will still need to be updated. It is still invoked (as
> "collect-ld") and it still needs to be able to understand the
> -use-gold/-use-ld options.
>
> Cheers
> Nick
>
>
>
>

Hi all,

One, may be stupid, question.

As I understand gcc checks linker properties in configure scripts
to adjust code-generation. You are suggesting to build a toolchain
with 2 linkers(bfd/gold). So question, which linker will be used
in gcc configure? What if another linker has other properties?
In the last case generated code will not correspond used linker.

Simple grep of crosstools build log shows the following:
checking dynamic linker characteristics... GNU/Linux ld.so
checking if the linker
(/home/sv/work/build_root/x86_64-gcc-4.4.3-glibc-2.3.2-0.43/build/build-gcc/./gcc/collect-ld
-m elf_x86_64) is GNU ld... yes
checking linker --as-needed support... yes
checking linker -Bstatic/-Bdynamic option... yes
checking linker EH-compatible garbage collection of sections... yes
checking linker for .hidden support... yes
checking linker position independent executable support... yes
checking linker PT_GNU_EH_FRAME support... yes
checking linker read-only and read-write section mixing... read-write
checking linker --sysroot support... yes

Are gold and bfd linkers similar in above aspects?
It was very simple grep, what if other linker properties
affects gcc code?

Thanks in advance
Vladimir Simonov
Reply | Threaded
Open this post in threaded view
|

Re: RFA/RFC: Enable both gold and ld in a single toolchain

Nick Clifton
Hi Vladimir,

> One, may be stupid, question.

Not stupid at - it is perfectly reasonable.

> As I understand gcc checks linker properties in configure scripts
> to adjust code-generation.

Correct.

> You are suggesting to build a toolchain
> with 2 linkers(bfd/gold).

Yes.

> So question, which linker will be used in gcc configure?

The bfd linker, if configuring gcc in a combined source tree along with
the binutils, otherwise the linker found in the system's search path.

This is actually a bug which I had not considered, albeit a minor one.
Even if the use configures with --enable-gold or --enable-gold=both/gold
then the gold sources will *not* be the ones examined for the capability
tests performed by gcc's configure scripts.  This should not matter
though, because of ...

> What if another linker has other properties?

That would be bad.

> Are gold and bfd linkers similar in above aspects?

... Yes.  In fact this is one of the main design goals of gold - to be
able to act as a drop in replacement for ld with all the same features
and capabilities.

One of the reasons that I created this patch in the first place was that
I wanted toolchain builders to be able to experiment with the new linker
(gold) whilst retaining the ability to use the known-good linker (ld.bfd).


Cheers
   Nick

Reply | Threaded
Open this post in threaded view
|

Re: RFA/RFC: Enable both gold and ld in a single toolchain

Nick Clifton
In reply to this post by H.J. Lu-30
Hi H.J.

>> exec-tool will still need to be updated.  It is still invoked (as
>> "collect-ld") and it still needs to be able to understand the
>> -use-gold/-use-ld options.

> Aren't they passed to collect2 directly with "${1+"$@"}"?

No it works the other way around:

   gcc invokes collect2.
   collect2 invokes collect-ld.  (In a built but not installed toolchain)
   collect-ld invokes ld-new.

Thus the decision as to which linker executable to use is made by the
collect-ld script, not the collect2 binary.

In the case of installed toolchain the sequence is different.  Here gcc
invokes collect2 which then invokes the linker directly.  Hence collect2
must also know about the -use-gold -use-ld switches.

Cheers
   Nick


Reply | Threaded
Open this post in threaded view
|

Re: RFA/RFC: Enable both gold and ld in a single toolchain

Steven Bosscher-6
In reply to this post by Nick Clifton
On Wed, Mar 17, 2010 at 8:57 AM, Nick Clifton <[hidden email]> wrote:
>> So question, which linker will be used in gcc configure?
>
> The bfd linker, if configuring gcc in a combined source tree along with the
> binutils, otherwise the linker found in the system's search path.

Does a build with -whopr and the linker plugin still work, then? (I
mean, it doesn't work for me at the moment, but for those with Really
Big Iron to play with...)

Ciao!
Steven
12