[U-Boot] Relocation size penalty calculation

[Joakim Tjernlund]

"J. William Campbell" <jwilliamcampbell at comcast.net> wrote on 14/10/2009 17:35:44:
>
> Joakim Tjernlund wrote:
> > "J. William Campbell" <jwilliamcampbell at comcast.net> wrote on 14/10/2009 01:48:52:
> >
> >> Joakim Tjernlund wrote:
> >>
> >>> Graeme Russ <graeme.russ at gmail.com> wrote on 13/10/2009 22:06:56:
> >>>
> >>>
> >>>
> >>>> On Tue, Oct 13, 2009 at 10:53 PM, Joakim Tjernlund
> >>>> <joakim.tjernlund at transmode.se> wrote:
> >>>>
> >>>>
> >>>>> Graeme Russ <graeme.russ at gmail.com> wrote on 13/10/2009 13:21:05:
> >>>>>
> >>>>>
> >>>>>> On Sun, Oct 11, 2009 at 11:51 PM, Joakim Tjernlund
> >>>>>> <joakim.tjernlund at transmode.se> wrote:
> >>>>>>
> >>>>>>
> >>>>>>> Graeme Russ <graeme.russ at 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