This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Exploring the possibility of linking objects with different relocation schemes.
- From: "Prafulla Thakare" <PrafullaT at KPITCummins dot com>
- To: <binutils at sources dot redhat dot com>
- Date: Tue, 14 Dec 2004 11:14:21 +0530
- Subject: Exploring the possibility of linking objects with different relocation schemes.
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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~