[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)