Folks:
	I seem to be tripping over a nasty ld (actually, BFD) bug on my SGI
	(mips) box with the new toolchain.

	The short of the story is that ld generates seemingly incorrect MIPS
	REL32 relocations for local symbols in shared libraries.  Using a 
	small example, take the following snippet of assembly:

        .globl  ptr
ptr:    .word   other_func

	instead of emitting (address of other_func), the new ld emits sth.
	like 0x90 instead.  When the run-time linker gets this symbol to 
	relocate, it ends up relocating it to somewhere in timbuktoo as it
	expected it to be an address based at the load address of the shared
	object, not based at zero.

	This had been hashed out on the binutils list a while back, and even
	fixed as well, but later changes either undid or broke the fix (I'm 
	not sure if the intent was to undo the fix or not).  Looks like a 
	fix was applied in rev 1.78 -> 1.79 of elf32-mips.c in the bintuils
	cvs, but was then undone in changes from rev. 1.87 -> 1.88, which
	where later pulled up to the binutils 2.11 branch.

	See http://sources.redhat.com/ml/binutils/1999-q3/msg00446.html for
	some background.

	It turns out the behaviour on NetBSD is slightly different than Ralf
	Baechle details in his post referenced above: the old (binutils 2.9.1
	based) actually generates the expected relocations; the new binutils
	2.11.2 based one does not.

	I've got a candidate fix, but being a GNU toolchain newbie, thought
	I'd pass it by folks here... I'll also send this off to the binutils
	folks assuming I can make it happen with a cleanly-configured set of
	binutils sources without any of the NetBSD make machinery (I'd like
	to make sure none of that needs to be considered before sending off
	a bug report to them).

	So attached are two things:
		(1) My patch, which is less than clean in that it still
		    contains debug printf's strewn about, but has the gist
		    of the proposed fix.  Line numbers may not match 100%
		    vs. the in-tree files since I removed one or two bits
		    of purely debugging additions by hand from the patch.

		(2) A slightly modified test case (stolen from Ralf's post,
		    modified to build on NetBSD and with added output from
		    both the new and old toolchains).  I've uuencoded the
		    tar.gz file for ease of transmission, since it's quite
		    small.

		    In the tarball, there are new-toolchain.out and old-
		    toolchain.out files, which correspond to the 2.11.2
		    based bintuils and the old 2.9.1 based binutils.

	I'd appreciate any feedback on this, as well as testing on mipsel,
	if anyone could do that (I only have BE systems available).

Thanks!
--rafal

Index: elf32-mips.c
===================================================================
RCS file: /cvsroot/gnusrc/gnu/dist/toolchain/bfd/elf32-mips.c,v
retrieving revision 1.4
diff -u -r1.4 elf32-mips.c
--- elf32-mips.c	2001/08/14 04:43:06	1.4
+++ elf32-mips.c	2001/10/04 01:49:12
@@ -199,7 +199,7 @@
 static boolean mips_elf_create_dynamic_relocation
   PARAMS ((bfd *, struct bfd_link_info *, const Elf_Internal_Rela *,
 	   struct mips_elf_link_hash_entry *, asection *,
-	   bfd_vma, bfd_vma *, asection *));
+	   bfd_vma, bfd_vma *, asection *, boolean));
 static void mips_elf_allocate_dynamic_relocations
   PARAMS ((bfd *, unsigned int));
 static boolean mips_elf_stub_section_p
@@ -5790,7 +5790,8 @@
 
 static boolean
 mips_elf_create_dynamic_relocation (output_bfd, info, rel, h, sec,
-				    symbol, addendp, input_section)
+				    symbol, addendp, input_section,
+				    local_p)
      bfd *output_bfd;
      struct bfd_link_info *info;
      const Elf_Internal_Rela *rel;
@@ -5799,6 +5800,7 @@
      bfd_vma symbol;
      bfd_vma *addendp;
      asection *input_section;
+     boolean local_p;
 {
   Elf_Internal_Rel outrel;
   boolean skip;
@@ -5886,14 +5888,23 @@
 	  *addendp += section_offset;
 	  /* Now, the relocation is just against the section.  */
 	  symbol = sec->output_section->vma;
+
+	  if (indx && local_p) {
+	      printf("mips_elf_create_dynamic_relocation(1): old type %d, "
+		     "adjusting addend %x by %x\n", r_type, *addendp, symbol);
+	      *addendp += symbol;
+	  }
 	}
 
       /* If the relocation was previously an absolute relocation and
 	 this symbol will not be referred to by the relocation, we must
 	 adjust it by the value we give it in the dynamic symbol table.
 	 Otherwise leave the job up to the dynamic linker.  */
-      if (!indx && r_type != R_MIPS_REL32)
+      if (!indx && r_type != R_MIPS_REL32) {
+        printf("mips_elf_create_dynamic_relocation(2): old type %d, adjusting "
+	       "addend %x by %x\n", r_type, *addendp, symbol);
 	*addendp += symbol;
+      }
 
       /* The relocation is always an REL32 relocation because we don't
 	 know where the shared library will wind up at load-time.  */
@@ -6330,7 +6351,8 @@
 						   sec,
 						   symbol,
 						   &value,
-						   input_section))
+						   input_section,
+						   local_p))
 	    return false;
 	}
       else

===================================================================
begin 640 nuke-ld-13.tar.gz
M'XL(`%[$NSL``^V776_:,!2&N8U_Q;GHQ58I6>)\6$+J-`I4ZP0$E792K[J0
MCS:KB5$25.W?SX8D9!2HJA6BK7XD8CL^)S[&>4_L9/$8JC10#?-3ZU"`I1/;
MAA8(](VR:``Q;8=8V-!YW=")9;?`/EA$-199[J4`K92Q?)_=TT,8TF,$=%R2
M]?H/O<<PBFGXYF/P-74L:_?Z6[JY6G^'&+HIUA];#FZ!_N:1;.&=KW]G`F?@
M96C0XR4-D'O^K7<S'/,&F_X,%K,Y0AZE;:#Q--,RAI`V_NJ.;M<WBK(-F:$Q
MR+#&D'+R8=#["&KVX*5A`"J#DR]P\EG<+Q[/.]7@5^+-8E]-0\I\;K'1G85^
M'K/D3`N\W./M:$&IZK,D#Y,\$^95)#X-O02".,N7-;31;B-%36>@1F7(ZTC!
M9VF(FEZ"1JGIG_\CV4'&>$G_AD$`'&*;IN.8#A8W;)'_I?X/CZ*QN="9,H]]
MC)"RE)LH[RF;4B5*V12)2UO1GE@:*!%CM5[>X+^RS\+O6TO_(G7]&PWI'QRG
MTC\F9*E_TY+Z/P8OZ#]@<7*/EM=Z!F@Z:LE;4=,_XT7.&/4?O#C1V&*O'%[#
M"_HW=&Q7^W][^?VW3$ON_X^"[P.HOM@29ZBL\WT@HD%]__YLYXR*T\&S?7QU
M3JC.!0)QK(2(I3,OAY!&)E:G\?TLGF<(]6Y'G>%E%Z[Z`[?;N;YT1[S:=:]Z
M$^1>7$SZU]S]^G;<AS_XWAG<]`'I!7!U-[P<3^Y&[J@T/.V<3TZ1H^M8MYW*
M@(]BXI6!R&.K;K*MNTB$M8GN/Y&\>N+=TI-%4#QZ-6@;015V-<$]%=`V*/WY
MO(J*55AC;YO_#TW+N=MIY=_T2RDY&K7\GX1/C>1_(&2=_PE_5T7^M^7Y[RC\
M5WD>[T[D*P-CUX>@T3QO_&6>QZ61L3_/%VXRSTLD$HE$(I%()!*)1/+.^`VJ
'4NZ``"@```-C
`
end

----
Rafal Boni                                                   rafal@mediaone.net