Exploring the possibility of linking objects with different relocation schemes.

Exploring the possibility of linking objects with different relocation schemes.

[Prafulla Thakare]

Hi,

We observed that the relocations supported in binutils 2.10.1 and
binutils 2.15 
for Renesas SH target are different. Because of this the result that
binaries 
produced by one version are incompatible with binaries produced by the
other. 
i.e. Existing binaries generated by binutils 2.10.1 cannot be linked
correctly 
by binutils 2.15.

There are many relocations schemes have been added in binutils 2.15 
(e.g. R_SH_LOOP_START) and are not supported by binutils 2.10. Due to
this, the 
relocation howto table is different in 2.10 and 2.15. There are many
other 
differences, of which few are listed below:

a. PIC related relocations are not supported in binutils 2.10 

b. In binutils 2.15, if the symbol is undefined, common, weak, or global
   (ELF shared libs), it is not replaced with the section symbol.
However, in 
   the case of binutils 2.10 that symbol is replaced with a section
symbol.

c. PIC related expressions are not supported in binutils 2.10, so no PIC
related 
   relocations are emitted and the assembler generates an error when any
of them 
   are defined.

d. Relocations related to loop bounds are not emitted in binutils 2.10.

What we intend to do is modify binutils 2.15, so as it will be able to
link the 
binaries generated using binutils 2.10 or 2.15. For this, binutils 2.15
is 
required to support the old relocation scheme (i.e. the relocation
scheme used 
by binutils 2.10.1) as well.

The basic problem in this is identifications of binary. As binaries
generated 
using binutils 2.10 or 2.15 do not keep any TAG to represent the
binutils version 
info. (Any inputs on this?)

Solution as per our understanding:
We will Change the ABI number in the object file to indicate the
relocation 
scheme used. This info thus will be available with all binaries
generated with 
binutils newer versions. Then change the linker to read the ABI number
and 
accordingly use the appropriate relocation scheme to link the supplied
binaries.  

Once modified, the linker will be able to correctly identify old ABI
binaries 
and new ABI binaries based on ABI number. The problem is the
intermediate ones 
that have the new ABI, but the old number. The command line arg will
allow 
users to tell the linker "Yes, I know you think this is the old ABI, but

honest - I know better". So, yes - the user would take full
responsibility on 
when to use this switch.

Also we are exploring the possibility of linking objects with different 
relocation schemes together. Can anybody suggest how feasible is to
modify 
present linker to link objects with different relocation scheme at the
same 
time?

Please comment on the above implementations idea. 
Do suggest, if it can be done in better way.

Regards,
Prafulla Thakare
KPIT Cummins InfoSystems Ltd.
Pune, India

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Free download of GNU based tool-chains for Renesas' SH and H8 Series. 
The following site also offers free technical support to its users. 
Visit http://www.kpitgnutools.com for details. 
Latest versions of KPIT GNU tools are released on Oct 1, 2004.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Re: Exploring the possibility of linking objects with different relocation schemes.

[Nick Clifton]

Hi Prafulla,

> Solution as per our understanding:
> We will Change the ABI number in the object file to indicate the
> relocation scheme used. 

This is the correct approach.

> Also we are exploring the possibility of linking objects with different 
> relocation schemes together. Can anybody suggest how feasible is to
> modify present linker to link objects with different relocation scheme 
 > at the same time?

This should be possible.  You may find that you cannot support the 
--emit-relocs switch since you would not be able to label the output 
file as containing both old and new ABI relocs.

Cheers
   Nick