Re: PATCH: Fix ld bootstrap test for ia64

Re: PATCH: Fix ld bootstrap test for ia64

[Jim Wilson]

I have RHL 7.2 beta (roswell2) on my IA-64 machine.  I built binutils using
the system compiler, ran the testsuite, and the ld-bootstrap tests worked.
I built binutils using a gcc 3.1 snapshot, ran the testsuite, and the
ld-bootstrap tests worked.  While doing this, I accidentally ran make
check using the gcc 3.1 snapshot against a objdir compiled with the system
compiler.  The ld-bootstrap tests failed in that case, but I don't think
it is reasonable to expect that to work, because these two compilers are
not compatible.

Next, I tried a server running RHL 7.1 beta (wolverine) with the roswell
glibc RPM installed over the top of the wolverine glibc.  On my first try,
the ld-bootstrap tests failed.  I started to look at this, and then noticed
that there was a random gcc snapshot on my path, along with a binutils
snapshot and a bunch of other stuff.  I tried again using the system compiler,
and this time the ld-bootstrap tests succeeded.

My suspicion here is that we should no longer have ld bootstrap testsuite
failures, provided that your system is recent enough, and that you haven't
replaced system tools/libraries.  If your system is even more recent, then
ld bootstrap should still work even if you have replaced some system tools.
We used to have trouble because we were still doing development work on ld,
but it has been pretty stable ever since the 2.11 release.

Jim

Re: PATCH: Fix ld bootstrap test for ia64

[H . J . Lu]

On Mon, Oct 01, 2001 at 05:13:26PM -0700, Jim Wilson wrote:
> 
> My suspicion here is that we should no longer have ld bootstrap testsuite
> failures, provided that your system is recent enough, and that you haven't
> replaced system tools/libraries.  If your system is even more recent, then
> ld bootstrap should still work even if you have replaced some system tools.
> We used to have trouble because we were still doing development work on ld,
> but it has been pretty stable ever since the 2.11 release.
> 

In that case, I assume ia64 is ok.


H.J.

Re: PATCH: Fix ld bootstrap test for ia64

[H . J . Lu]

On Mon, Oct 01, 2001 at 09:43:02PM -0700, H . J . Lu wrote:
> On Mon, Oct 01, 2001 at 05:13:26PM -0700, Jim Wilson wrote:
> > 
> > My suspicion here is that we should no longer have ld bootstrap testsuite
> > failures, provided that your system is recent enough, and that you haven't
> > replaced system tools/libraries.  If your system is even more recent, then
> > ld bootstrap should still work even if you have replaced some system tools.
> > We used to have trouble because we were still doing development work on ld,
> > but it has been pretty stable ever since the 2.11 release.
> > 
> 
> In that case, I assume ia64 is ok.
> 

One more thing, I used

# .../configure --enable-64-bit-bfd --enable-targets=all

I don't know if it makes a difference or not.


H.J.

Re: PATCH: Fix ld bootstrap test for ia64

[Jim Wilson]

># .../configure --enable-64-bit-bfd --enable-targets=all

I reproduced the problem with this configure command.

It didn't seem right to me that we still have this problem, so I investigated.
Some symbols are getting different gp offsets.  These entries are in a
bfd_hash_table, and offsets are assigned in order via a simple bfd hash table
traverse, so that implies that the hash tables are different.

I tracked this down to get_dyn_sym_info in bfd/elfxx-ia64.c.  This creates
some hash table entries at run time for which we have no symbol name, so
it synthesizes one using the abfd address and unique relocation info.
    sprintf (addr_name, "%p:%lx", (void *) abfd, ELFNN_R_SYM (rel->r_info));
But the abfd address can vary if the linkers are not identical, and since
ld1 and ld2 are built differently, this causes the ld2 and ld3 linkers to be
different.

So we either need to build an ld4 in the testsuite, or else we need to use
a more deterministic method for creating fake symbol names here.

Jim

Re: PATCH: Fix ld bootstrap test for ia64

[Alan Modra]

On Tue, Oct 02, 2001 at 07:13:14PM -0700, Jim Wilson wrote:
> 
> or else we need to use
> a more deterministic method for creating fake symbol names here.

asection->id is designed for just this purpose.

Re: PATCH: Fix ld bootstrap test for ia64

[Jim Wilson]

Thanks.  hppa_stub_name in bfd/elf32-hppa.c seems to be the answer.  I will
try experimenting with this in the IA-64 port tomorrow.

Jim

PATCH: Fix ld bootstrap test for ia64

[H . J . Lu]

It has been a while for me to check binutils on ia64. It looks like
we have to always rebuild tmpdir/ld2 with tmpdir/ld3 on ia64 like
Linux/mips. Could someone please verify it on ia64?


H.J.
----
2001-09-29  H.J. Lu  <hjl@gnu.org>

	* ld-bootstrap/bootstrap.exp: Always rebuild tmpdir/ld2 with
	tmpdir/ld3 on ia64.

Index: ld-bootstrap/bootstrap.exp
===================================================================
RCS file: /work/cvs/gnu/binutils/ld/testsuite/ld-bootstrap/bootstrap.exp,v
retrieving revision 1.5
diff -u -p -r1.5 bootstrap.exp
--- ld-bootstrap/bootstrap.exp	2001/06/06 22:10:34	1.5
+++ ld-bootstrap/bootstrap.exp	2001/09/30 04:17:20
@@ -104,26 +104,15 @@ foreach flags {"" "strip" "--static" "--
 	continue
     }
 
-    if {"$flags" == "--static"} {
-	if { [istarget ia64-*-elf*]
-	     || [istarget ia64-*-linux*] } {
-	    # On ia64, tmpdir/ld2 != tmpdir/ld3 is normal since they are
-	    # generated by different linkers, tmpdir/ld1 and tmpdir/ld2.
-	    # So we rebuild tmpdir/ld2 with tmpdir/ld3.
-	    if ![ld_link tmpdir/ld3 tmpdir/ld2 "$flags $OFILES $BFDLIB $LIBIBERTY"] {
-		fail $testname
-		continue
-	    }
-	}
-    } else {
-	if { [istarget mips*-*-linux*] } {
-	    # On Linux/mips, tmpdir/ld2 != tmpdir/ld3 is normal since
-	    # they are generated by different linkers, tmpdir/ld1 and
-	    # tmpdir/ld2. So we rebuild tmpdir/ld2 with tmpdir/ld3.
-	    if ![ld_link tmpdir/ld3 tmpdir/ld2 "$flags $OFILES $BFDLIB $LIBIBERTY"] {
-		fail $testname
-		continue
-	    }
+    if { [istarget ia64-*-elf*]
+	 || [istarget ia64-*-linux*]
+	 || [istarget mips*-*-linux*] } {
+	# On ia64 and Linux/mips, tmpdir/ld2 != tmpdir/ld3 is normal
+	# since they are generated by different linkers, tmpdir/ld1
+	# and tmpdir/ld2. So we rebuild tmpdir/ld2 with tmpdir/ld3.
+	if ![ld_link tmpdir/ld3 tmpdir/ld2 "$flags $OFILES $BFDLIB $LIBIBERTY"] {
+	    fail $testname
+	    continue
 	}
     }