[PATCH] Update relocation values for ARC platform.

[PATCH] Update relocation values for ARC platform.

[Ramana Radhakrishnan]

[-- Attachment #1: Type: text/plain, Size: 265 bytes --]

Hi ,

This patch corrects the values of the relocation types for
the ARC platform. Tested by building cross arc-elf32 and 
running the tests with no regressions.

Ok to commit. ?

cheers
Ramana
---
Ramana Radhakrishnan
GNU Tools
codito ergo sum (www.codito.com)




[-- Attachment #2: chlg --]
[-- Type: text/plain, Size: 266 bytes --]

2005-04-21  Ramana Radhakrishnan  <ramana.radhakrishnan@codito.com>

	* arc.h: Correct relocation values for R_ARC_32,R_ARC_B26,
	R_ARC_B22_PCREL. 
	* elf32-arc.c(R_ARC_standard):Define.
	(bfd_elf32_bfd_reloc_type_lookup):Use it.
	(arc_info_to_howto_rel):Use it.




[-- Attachment #3: arc-relocations-corrections-patch --]
[-- Type: text/plain, Size: 1904 bytes --]

Index: include/elf/arc.h
===================================================================
RCS file: /cvs/src/src/include/elf/arc.h,v
retrieving revision 1.5
diff -a -u -r1.5 arc.h
--- include/elf/arc.h	14 Mar 2001 02:27:44 -0000	1.5
+++ include/elf/arc.h	21 Apr 2005 09:49:44 -0000
@@ -29,9 +29,10 @@
 
 START_RELOC_NUMBERS (elf_arc_reloc_type)
   RELOC_NUMBER (R_ARC_NONE, 0)
-  RELOC_NUMBER (R_ARC_32, 1)
-  RELOC_NUMBER (R_ARC_B26, 2)
-  RELOC_NUMBER (R_ARC_B22_PCREL, 3)
+     /* We have a gap here.  */
+  RELOC_NUMBER (R_ARC_32, 4)
+  RELOC_NUMBER (R_ARC_B26, 5)
+  RELOC_NUMBER (R_ARC_B22_PCREL, 6)
 END_RELOC_NUMBERS (R_ARC_max)
 
 /* Processor specific flags for the ELF header e_flags field.  */
Index: bfd/elf32-arc.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-arc.c,v
retrieving revision 1.14
diff -a -u -r1.14 elf32-arc.c
--- bfd/elf32-arc.c	30 Nov 2002 08:39:37 -0000	1.14
+++ bfd/elf32-arc.c	21 Apr 2005 09:49:44 -0000
@@ -58,7 +58,8 @@
 	 0,			/* src_mask  */
 	 0,			/* dst_mask  */
 	 FALSE),		/* pcrel_offset  */
-
+  /* There is a gap of 3 here between R_ARC_NONE and R_ARC_32.  */
+  #define R_ARC_standard (R_ARC_32 - 1)
   /* A standard 32 bit relocation.  */
   HOWTO (R_ARC_32,		/* type  */
 	 0,			/* rightshift  */
@@ -131,7 +132,8 @@
 
   for (i = ARRAY_SIZE (arc_reloc_map); i--;)
     if (arc_reloc_map[i].bfd_reloc_val == code)
-      return elf_arc_howto_table + arc_reloc_map[i].elf_reloc_val;
+      return (elf_arc_howto_table + arc_reloc_map[i].elf_reloc_val 
+	      - R_ARC_standard);
 
   return NULL;
 }
@@ -148,7 +150,7 @@
 
   r_type = ELF32_R_TYPE (dst->r_info);
   BFD_ASSERT (r_type < (unsigned int) R_ARC_max);
-  cache_ptr->howto = &elf_arc_howto_table[r_type];
+  cache_ptr->howto = &elf_arc_howto_table[r_type - R_ARC_standard];
 }
 
 /* Set the right machine number for an ARC ELF file.  */

Re: [PATCH] Update relocation values for ARC platform.

[Nick Clifton]

Hi Ramana,

> This patch corrects the values of the relocation types for
> the ARC platform. Tested by building cross arc-elf32 and running the 
> tests with no regressions.

I am worried about this.  What has happened to the old relocation values 
(1, 2, 3) ?  What about backwards compatibility ?

Cheers
   Nick

Re: [PATCH] Update relocation values for ARC platform.

[Ramana Radhakrishnan]

Hi Nick,

>> This patch corrects the values of the relocation types for
>> the ARC platform. Tested by building cross arc-elf32 and running the 
>> tests with no regressions.
> 
> 
> I am worried about this.  What has happened to the old relocation values 
> (1, 2, 3) ?  What about backwards compatibility ?

FSF mainline was not ABI compliant with respect to these 
relocation values. (The relocation values 1, 2 and 3 are 
actually reserved for the relocation types R_ARC_8, 
R_ARC_16, R_ARC_24. ostensibly generated by the other 
toolchain for the ARC cores. ) which the GNU tools does not 
generate / handle currently.Mainline seems to have the 
values of 1,2,3 for these relocation types since the first 
revision.

With respect to backwards compatibility, if anything this 
should enable users to link in GNU compiled binaries with 
the other propreitary toolchain with a few more patches that 
are still in my pipeline. A persistent complaint has been 
this inability to link object files generated by the 2 
toolsets for the ARC platform .

Would a NEWS item indicating this change  be a valid thing 
to do indicating that mainline would be broken w.r.t 2.16 
branch. ?  Or would you want to put in some sort of version 
checks in the linker based on version info emitted by the 
assembler ?


cheers
Ramana

---
Ramana Radhakrishnan
GNU Tools
codito ergo sum (www.codito.com)

Re: [PATCH] Update relocation values for ARC platform.

[Nick Clifton]

Hi Ramana,

>> I am worried about this.  What has happened to the old relocation 
>> values (1, 2, 3) ?  What about backwards compatibility ?

> FSF mainline was not ABI compliant with respect to these relocation 
> values. (The relocation values 1, 2 and 3 are actually reserved for the 
> relocation types R_ARC_8, R_ARC_16, R_ARC_24. ostensibly generated by 
> the other toolchain for the ARC cores. ) which the GNU tools does not 
> generate / handle currently.Mainline seems to have the values of 1,2,3 
> for these relocation types since the first revision.
> 
> With respect to backwards compatibility, if anything this should enable 
> users to link in GNU compiled binaries with the other propreitary 
> toolchain with a few more patches that are still in my pipeline. A 
> persistent complaint has been this inability to link object files 
> generated by the 2 toolsets for the ARC platform .

Ok - that is a reasonable reason to break backwards compatibility,

> Would a NEWS item indicating this change  be a valid thing to do 
> indicating that mainline would be broken w.r.t 2.16 branch. ?

Maybe, but see below.

> Or would 
> you want to put in some sort of version checks in the linker based on 
> version info emitted by the assembler ?

Well I think that a nicer solution might be to be put code into 
bfd/elf32-arc.c to handle the "old" style relocation values with a 
warning that support for them will be removed with the next release of 
binutils (ie 2.17).  Obviously you would then have to remember to remove 
this support after the 2.17 branch is cut, whenever that might be.

If this is too long term for you, eg if you are planning to update the 
bfd sources in the near future so that they hand the R_ARC_8, R_ARC_16 
and R_ARC24 relocs, then perhaps a heuristic could be developed to 
distinguish between an object with the old (non ABI compliant) relocs 
and an object file with relocs created by a foreign compiler.  The 
linker could then issue a suitable error message saying that the old 
relocs are no longer supported and that a 2.16 version of the linker is 
needed.

Cheers
   Nick

Re: [PATCH] Update relocation values for ARC platform.

[Ramana Radhakrishnan]

Hi Nick,

> Ok - that is a reasonable reason to break backwards compatibility,
> 
>> Would a NEWS item indicating this change  be a valid thing to do 
>> indicating that mainline would be broken w.r.t 2.16 branch. ?
> 
> 
> Maybe, but see below.
> 
>> Or would you want to put in some sort of version checks in the linker 
>> based on version info emitted by the assembler ?
> 
> 
> Well I think that a nicer solution might be to be put code into 
> bfd/elf32-arc.c to handle the "old" style relocation values with a 
> warning that support for them will be removed with the next release of 
> binutils (ie 2.17).  Obviously you would then have to remember to remove 
> this support after the 2.17 branch is cut, whenever that might be.
> 
> If this is too long term for you, eg if you are planning to update the 
> bfd sources in the near future so that they hand the R_ARC_8, R_ARC_16 
> and R_ARC24 relocs, then perhaps a heuristic could be developed to 
> distinguish between an object with the old (non ABI compliant) relocs 
> and an object file with relocs created by a foreign compiler.  The 
> linker could then issue a suitable error message saying that the old 
> relocs are no longer supported and that a 2.16 version of the linker is 
> needed.

Let me work out the necessary heuristic. Yes, R_ARC_8, 
R_ARC_16 and  R_ARC_24 need to be generated since that would 
be the correct behaviour with the .byte, .2byte and .3byte 
directives (PR gas/873) is the corresponding bug report. (It 
does not make sense to generate a 4byte reloc for a (1/2/3) 
byte field.)

cheers
Ramana


-- 
Ramana Radhakrishnan
GNU Tools
codito ergo sum (www.codito.com)