Joakim Tjernlund wrote: > "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? > 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 > > > > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot