This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: Link-time relaxing for m68k ELF
- To: msokolov at ivan dot Harhan dot ORG
- Subject: Re: Link-time relaxing for m68k ELF
- From: Ian Lance Taylor <ian at zembu dot com>
- Date: 17 Apr 2000 23:02:36 -0700
- CC: binutils at sourceware dot cygnus dot com
- References: <0004180257.AA03735@ivan.Harhan.ORG>
Date: Mon, 17 Apr 00 21:57:54 CDT
From: msokolov@ivan.Harhan.ORG (Michael Sokolov)
I'm now ready to dive in, but before I do, I just wanted to discuss with Ian
and others how I'm going to do it, to make sure it's right.
I think that everything you say makes a lot of sense.
The above considerations bring me to the following strategy: invent new GNU
extension reloc types that are just like normal absolute and PC-relative relocs
(specifically, we'll need 32-bit absolute, 32-bit PC-relative, and 16-bit PC-
relative), but indicate relaxability.
If you want to handle all possible cases, you will need to have a
quite complex set of opcode translations. It will be more tractable
to only handle cases which could reasonably be generated by a
compiler.
Here's what I'm thinking about. m68k ELF uses .rela, which means that the
contents of the relocation slots in the section image is not used. What about
storing the relaxation control information there? I think we will still need
special relocs to denote relaxability, as I think in the ABI-compliant objects
the contents of the relocation slots is undefined, not necessarily zero.
However, these special relocs would only indicate relaxability and the use of
our GNU extension, and then the relocation slots would be consulted for the
rest.
This is weird but I think it's doable.
An alternative would be to only permit relaxing for a direct symbolic
reference, and to use the r_addend field to hold the offset to the
start of the instruction. A non-direct reference requires a
conventional non-relaxable reloc.
Or, similarly, you can arbitrarily declare that r_addend is limited to
29 bits, and use 3 bits for the offset to the start of the
instruction. A reference using a larger addend requires a
conventional non-relaxable reloc.
Or you could burn relocation space, and allocate 24 relocs, and use
three bits for the offset to the start of the instruction.
If you want to go really crazy, you could relax GOT and PLT
references, too. Then you would need even more relocations. But it's
probably not worth it.
Ian