This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]