"J. William Campbell" <jwilliamcampb...@comcast.net> wrote on 14/10/2009 17:35:44: > > Joakim Tjernlund wrote: > > "J. William Campbell" <jwilliamcampb...@comcast.net> wrote on 14/10/2009 > > 01:48:52: > > > >> Joakim Tjernlund wrote: > >> > >>> Graeme Russ <graeme.r...@gmail.com> wrote on 13/10/2009 22:06:56: > >>> > >>> > >>> > >>>> On Tue, Oct 13, 2009 at 10:53 PM, Joakim Tjernlund > >>>> <joakim.tjernl...@transmode.se> wrote: > >>>> > >>>> > >>>>> Graeme Russ <graeme.r...@gmail.com> wrote on 13/10/2009 13:21:05: > >>>>> > >>>>> > >>>>>> On Sun, Oct 11, 2009 at 11:51 PM, Joakim Tjernlund > >>>>>> <joakim.tjernl...@transmode.se> wrote: > >>>>>> > >>>>>> > >>>>>>> Graeme Russ <graeme.r...@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? > > 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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
