[U-Boot] Relocation size penalty calculation

[Joakim Tjernlund]

"J. William Campbell" <jwilliamcampbell at comcast.net> wrote on 13/10/2009 18:30:43:
>
> Joakim Tjernlund 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 :)]
> >>
> >>
> >>>> So, all that is left are .dynsym and .dynamic ...
> >>>>   .dynsym
> >>>>     - Contains 70 entries (16 bytes each, 1120 bytes)
> >>>>     - 44 entries mimic those entries in .got which are not relocated
> >>>>     - 21 entries are the remaining symbols exported from the linker
> >>>>       script
> >>>>     - 4 entries are labels defined in inline asm and used in C
> >>>>
> >>> Try adding proper asm declarations. Look at what gcc
> >>> generates for a function/variable and mimic these.
> >>>
> >> Thanks - Now .dynsym contains only exports from the linker script
> >>
> > :)
> >
> >>>>     - 1 entry is a NULL entry
> >>>>
> >>>>   .dynamic
> >>>>     - 88 bytes
> >>>>     - Array of Elf32_Dyn
> >>>>     - typedef struct {
> >>>>           Elf32_Sword     d_tag;
> >>>>           union {
> >>>>               Elf32_Word  d_val;
> >>>>               Elf32_Addr  d_ptr;
> >>>>           } d_un;
> >>>>       } Elf32_Dyn;
> >>>>     - 0x11 entries
> >>>>       [00] 0x00000010, 0x00000000 DT_SYMBOLIC, (ignored)
> >>>>       [01] 0x00000004, 0x38059994 DT_HASH, points to .hash
> >>>>       [02] 0x00000005, 0x380595AB DT_STRTAB, points to .dynstr
> >>>>       [03] 0x00000006, 0x3805BDCC DT_SYMTAB, points to .dynsym
> >>>>       [04] 0x0000000A, 0x000003E6 DT_STRSZ, size of .dynstr
> >>>>       [05] 0x0000000B, 0x00000010 DT_SYMENT, ???
> >>>>       [06] 0x00000015, 0x00000000 DT_DEBUG, ???
> >>>>       [07] 0x00000011, 0x3805A8F4 DT_REL, points to .rel.text
> >>>>       [08] 0x00000012, 0x000014D8 DT_RELSZ, ???
> >>>>
> >>> How big DT_REL is
> >>>
> >>>>       [09] 0x00000013, 0x00000008 DT_RELENT, ???
> >>>>
> >>> hmm, cannot remeber :)
> >>>
> >> How big an entry in DT_REL is
> >>
> >
> > Right, how could I forget :)
> >
> >>>>       [0a] 0x00000016, 0x00000000 DT_TEXTREL, ???
> >>>>
> >>> Oops, you got text relocations. This is generally a bad thing.
> >>> TEXTREL is commonly caused by asm code that arent truly pic so it needs
> >>> to modify the .text segment to adjust for relocation.
> >>> You should get rid of this one. Look for DT_TEXTREL in .o files to find
> >>> the culprit.
> >>>
> >>>
> >> Alas I cannot - The relocations are a result of loading a register with a
> >> return address when calling show_boot_progress in the very early stages of
> >> initialisation prior to the stack becoming available. The x86 does not
> >> allow direct access to the IP so the only way to find the 'current
> >> execution address' is to 'call' to the next instruction and pop the return
> >> address off the stack
> >>
> >
> > hmm, same as ppc but that in it self should not cause a TEXREL, should it?
> > Ahh, the 'call' is absolute, not relative? I guess there is some way around it
> > but it is not important ATM I guess.
> >
> > 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.
> >
> I think this approach will turn out to be a big win. At present, the
> problem with just using the relocs is that objcopy is stripping them out
> when u-boot.bin is created, as I understand it. It seems this can be
> solved by changing the command switches appropriately, like using
> --strip-unneeded. In any case, there is some combination of switches
> that will preserve the relocation data. The executable code will get
> smaller, there will be no .got, and the relocation data will be larger
> (than with -fpic). In total size, it probably will be slightly smaller,
> but that is a guess. The most important benefit of this approach is that
> it will work for all architectures, thereby solving the problem once and
> forever! Even if the result is a bit larger, the RAM footprint will be
> reduced by the smaller object code size (since the relocation data need
> not be copied into ram).Having this approach as an option would be real
> nice, since it would always "just work".

Yes, I had this in the back of my head. I do think some other arch than ppc
will have to try this out though :)
I am not 100% sure this will work with my end goal, true PIC so I can load
the same img anywhere in flash.

 Jocke