R_MIPS_26 testcase

R_MIPS_26 testcase

[Ralf Baechle]

Hi Mark,

this testcase which is just a little bit different from from #5 demonstrates
the defect of the handling of R_MIPS_26 mentioned in my other email.

  Ralf

begin 664 nuke-ld-6.tar.gz
M'XL("`-8J#<"`VYU:V4M;&0M-BYT87(`[=9/:X,P&`9PK\FG>&$];(=TFF@$
MQV`;/8S1KH6QPRX#5RVSC5JTPMBGGTKIGPVZ4UO6/3]0XZL8\.V3FE6S6)A(
MZ$MK;\BU?<\CBXA\[6X=EVPB[7O2]I2O)9%C:RDM\JP#J,I%6!!916@FN^[[
M[?H?E:WZ7SK=<C]S.+:M77='_UW5]M]12DO5]-]1GK;(1O_WCF7Y_&IC8^R,
MIO4[H3)/XWJ4S;@%IVLC__)H^=?.>OV77IM_K9#_8^2?_RB\5\5GP*:A8<T(
MJ\&IYG\0SN))8N+#YU])?Y5_K9O\2^4B_P=Q^T37E";S4I@DJSY$6/)^;[MD
M(CZ\>^@]#T;;]?QM&E7IG//0F(":'Q+GW=']\/%E>=;L`E9_5^94_[GDG'7.
M^[T+$@6)G#HWU'EM2LMGU_6H+JX?,39QF%&4E(MVQ+^=!YR)(B4QH=4$[:PT
<SHL8JQ0```````````````#\3U]QZ0LG`"@`````
`
end

Re: R_MIPS_26 testcase

[Mark Mitchell]

I think I already fixed this.  I get:

  Disassembly of section .text:

  0000000000000000 <bar-0x18000>:
	  ...

  0000000000018000 <bar>:
     18000:	3c020002 	lui	$v0,0x2
			  18000: R_MIPS_HI16	.text
     18004:	24428000 	addiu	$v0,$v0,-32768
			  18004: R_MIPS_LO16	.text
	  ...

which looks like the right thing to me: 0x20000 - 0x8000 = 0x18000
unless I'm really losing it.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: R_MIPS_26 testcase

[Ralf Baechle]

On Wed, Aug 04, 1999 at 01:49:26PM -0700, Mark Mitchell wrote:

> I think I already fixed this.  I get:
> 
>   Disassembly of section .text:
> 
>   0000000000000000 <bar-0x18000>:
> 	  ...
> 
>   0000000000018000 <bar>:
>      18000:	3c020002 	lui	$v0,0x2
> 			  18000: R_MIPS_HI16	.text
>      18004:	24428000 	addiu	$v0,$v0,-32768
> 			  18004: R_MIPS_LO16	.text
> 	  ...
> 
> which looks like the right thing to me: 0x20000 - 0x8000 = 0x18000
> unless I'm really losing it.

Yep, test cases #7 and #8 are ok now.  #6 still is broken.  Shifting
left of the the jump destination has to be done before adding
something to it like in this patch fragment:

@@ -6581,6 +6573,9 @@
            /* There's nothing to do for non-local relocations.  */
            continue;
 
+          if (r_type == R_MIPS_26)
+              addend <<= 2;
+
          r_symndx = ELF32_R_SYM (rel->r_info);
          sym = local_syms + r_symndx;
          if (ELF_ST_TYPE (sym->st_info) == STT_SECTION)

  Ralf

Re: R_MIPS_26 testcase

[Ralf Baechle]

This seems to fix test case #6.

>  else if (r_type == R_MIPS16_26 || r_type == R_MIPS16_26)
                      ^^^^^^^^^^^              ^^^^^^^^^^^

Note that nice typo in your code ...

  Ralf

Index: binutils-cygnus/bfd/elf32-mips.c
===================================================================
RCS file: /cvs/binutils/binutils/bfd/elf32-mips.c,v
retrieving revision 1.44
diff -u -r1.44 elf32-mips.c
--- elf32-mips.c	1999/08/04 16:32:34	1.44
+++ elf32-mips.c	1999/08/04 21:22:52
@@ -6599,6 +6599,13 @@
 	    /* There's nothing to do for non-local relocations.  */
 	    continue;
 
+	  if (r_type == R_MIPS_26 || r_type == R_MIPS16_26)
+	    /* The addend is stored without its two least
+	       significant bits (which are always zero.)  In a
+	       non-relocateable link, calculate_relocation will do
+	       this shift; here, we must do it ourselves.  */
+	    addend <<= 2;
+
 	  r_symndx = ELF32_R_SYM (rel->r_info);
 	  sym = local_syms + r_symndx;
 	  if (ELF_ST_TYPE (sym->st_info) == STT_SECTION)
@@ -6610,12 +6617,6 @@
 	      || r_type == R_MIPS_GPREL32)
 	    addend -= (_bfd_get_gp_value (output_bfd)
 		       - _bfd_get_gp_value (input_bfd));
-	  else if (r_type == R_MIPS16_26 || r_type == R_MIPS16_26)
-	    /* The addend is stored without its two least
-	       significant bits (which are always zero.)  In a
-	       non-relocateable link, calculate_relocation will do
-	       this shift; here, we must do it ourselves.  */
-	    addend <<= 2;
 
 	  /* If the relocation is for a R_MIPS_HI16 or R_MIPS_GOT16,
 	     then we only want to write out the high-order 16 bits.

Re: R_MIPS_26 testcase

[Mark Mitchell]

>>>>> "Ralf" == Ralf Baechle <ralf@uni-koblenz.de> writes:

    Ralf> This seems to fix test case #6.

    >> else if (r_type == R_MIPS16_26 || r_type == R_MIPS16_26)
    Ralf>                       ^^^^^^^^^^^ ^^^^^^^^^^^

!#@!
 
I'm going to take a nap now.  When I wake up, I promise to be a saner
person.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: R_MIPS_26 testcase

[Ralf Baechle]

On Wed, Aug 04, 1999 at 03:26:25PM -0700, Mark Mitchell wrote:

> >>>>> "Ralf" == Ralf Baechle <ralf@uni-koblenz.de> writes:
> 
>     Ralf> This seems to fix test case #6.
> 
>     >> else if (r_type == R_MIPS16_26 || r_type == R_MIPS16_26)
>     Ralf>                       ^^^^^^^^^^^ ^^^^^^^^^^^
> 
> !#@!
>  
> I'm going to take a nap now.  When I wake up, I promise to be a saner
> person.

Just to make your waking sweeter, latest cvs-binutils plus the R_MIPS_26
patch from my other email plus your elflink.h patch build a working
Linux kernel!

  Ralf

Re: R_MIPS_26 testcase

[Mark Mitchell]

>>>>> "Ralf" == Ralf Baechle <ralf@uni-koblenz.de> writes:

    Ralf> Just to make your waking sweeter, latest cvs-binutils plus
    Ralf> the R_MIPS_26 patch from my other email plus your elflink.h
    Ralf> patch build a working Linux kernel!

I must still be sleeping.  I thought you said something worked.  What
a nice dream I'm having ...

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: R_MIPS_26 testcase

[Ralf Baechle]

On Wed, Aug 04, 1999 at 06:20:07PM -0700, Mark Mitchell wrote:

> >>>>> "Ralf" == Ralf Baechle <ralf@uni-koblenz.de> writes:
> 
>     Ralf> Just to make your waking sweeter, latest cvs-binutils plus
>     Ralf> the R_MIPS_26 patch from my other email plus your elflink.h
>     Ralf> patch build a working Linux kernel!
> 
> I must still be sleeping.  I thought you said something worked.  What
> a nice dream I'm having ...

Enjoy that feeling ...  before you read my other email ...

  Ralf

Re: R_MIPS_26 testcase

[Mark Mitchell]

Ralf --

  Let's take this stuff off the binutils list.  I'm sure we're boring
everyone.

  I suggest that you and I continue hashing out the bugs, and that
when we're done that we communicate that fact back to the list.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com