Joakim Tjernlund wrote:
"J. William Campbell" jwilliamcampbell@comcast.net wrote on 14/10/2009 17:35:44:
Joakim Tjernlund wrote:
"J. William Campbell" jwilliamcampbell@comcast.net wrote on 14/10/2009 01:48:52:
Joakim Tjernlund wrote:
Graeme Russ graeme.russ@gmail.com wrote on 13/10/2009 22:06:56:
On Tue, Oct 13, 2009 at 10:53 PM, Joakim Tjernlund joakim.tjernlund@transmode.se wrote:
> Graeme Russ graeme.russ@gmail.com wrote on 13/10/2009 13:21:05: > > > >> On Sun, Oct 11, 2009 at 11:51 PM, Joakim Tjernlund >> joakim.tjernlund@transmode.se wrote: >> >> >> >>> Graeme Russ graeme.russ@gmail.com wrote on 11/10/2009 12:47:19: >>> >>> >>> >> [Massive Snip :)] >>
[Yet another SNIP :)]
> Evil idea, skip -fpic et. all and add the full reloc procedure > to relocate by rewriting directly in TEXT segment. Then you save space > but you need more relocation code. Something like dl_do_reloc from > uClibc. Wonder how much extra code that would be? Not too much I think. > > > > With the following flags
PLATFORM_RELFLAGS += -fvisibility=hidden PLATFORM_CPPFLAGS += -fno-dwarf2-cfi-asm PLATFORM_LDFLAGS += -pic --emit-relocs -Bsymbolic -Bsymbolic-functions
I get no .got, but a lot of R_386_PC32 and R_386_32 relocations. I think this might mean I need the symbol table in the binary in order to resolve them
BTW, how many relocs do you get compared with -fPIC? I suspect you more now but hopefully not that many more.
Possibly, but I think you only need to add an offset to all those relocs.
Almost right. The relocations specify a symbol value that needs to be added to the data in memory to relocate the reference. The symbol values involved should be the start of the text section for program references, the start of the uninitialized data section for bss references, and the start of the data section for initialized data and constants. So there are about four symbols whose value you need to keep. Take a look at http://refspecs.freestandards.org/elf/elf.pdf (which you have probably already looked at) and it tells you what to do with R_386_PC32 ad R_386_32 relocations. Hopefully the objcopy with the --strip-unneeded will remove all the symbols you don't actually need, but I don't know that for sure. Note also that you can change the section flags of a section marked noload to load.
Still think you can get away with just ADDING an offset. The image is linked to a specific address and then you move the whole image to a new address. Therefore you should be able to read the current address, add offset, write back the
new address.
Normally one do what you describe but here we know that the whole img has moved so we don't have to do calculate the new address from scratch.
If the addresses of the bss, text, and data segments change by the same value, I think you are correct. However, if the text and data/bss segments are moved by different offsets, naturally the relocations would be different. One reason to retain this capability would be to allow the u-boot copy to execute in place in NOR flash while re-locating the read-write storage once memory has been sized. Having different relocation factors is not much worse than just one, and it may be just as easy to get working initially as a single relocation constant.
How do figure that? You need to rewrite the insn to access the moved data/bss and they are in flash, did I miss something?
No, I did. You are quite correct, there would be references in flash that couldn't be fixed. Sorry about that.
Best Regards, Bill Campbell
FWIW, the "ultimate" solution to minimum relocation size is a post-processing step that creates "several" arrays of relocation offsets as two byte quantities. This reduces the cost of each relocation entry to just a bit more than two bytes (there is a small overhead for array size, MSB values and relocation offset selection.) Naturally, this is much less than the ELF version of the same relocations, because we do not need to retain as much information and ELF doesn't worry about size that much.. This may pacify users for which the flash size of the image is critical, at the expense of an extra link step. Naturally, getting things to work with "standard ELF" is the most important step, and probably enough for most people.
That would save 2+4 bytes/reloc on REL arches and 2+4+4 on RELA(ppc) (provided one can ignore r_addend)
But yes, this is probably too "fancy" for the moment.
Jocke