This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [PATCH] Update relocation values for ARC platform.
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)