[U-Boot] [PATCH 0/2] Make sure 85xx bss doesn't start at 0x0

[Joakim Tjernlund]

>
> On Wed, Oct 7, 2009 at 5:55 PM, Wolfgang Denk <wd at denx.de> wrote:
> > Dear Graeme Russ,
> >
> > In message <d66caabb0910061824s4165d33bu5d5213f6783c09d0 at mail.gmail.com> you wrote:
> >>
> >> I think that even the -mrelocatable / .fixup method may not be needed at
> >> all. -pie / -pic used by themselves creates enough information for an OS
> >> dynamic loader to relocate an executable, so why not U-Boot? Given that
> >> the type and location of each section is easily determined, a striped
> >> down dynamic loader can provide a platform-independent relocation scheme.
> >
> > One reason for not using ELF images for the boot loader is size. The
> > ELF header alone is often more than we would be willing to accept, not
> > to mention the additional code.
> >
>
> But the headers get stripped from the final binary. All we are left with in
> order to locate the ELF section data are the symbols exported from the
> linker script
>
> The extra code is only three very tight for-loops. I had them wrapped in
> functions to improve readability, but they are good inline candidates (only
> called once each) and I doubt they use much code space at all (I'll send
> through actual numbers soon)

But how much space in the extra sections you link in?

if size is comparable with fixup ptrs we should probably
consider using the same for ppc. Then we can use -fpic/-fpie and
that is significantly smaller then -fPIC on PPC.

>
> Question is, does -mrelocatable result in smaller .got (et al) are is the
> .fixup section adding extra size for the sake of ease of implementation?

fixup section expands with lots of ptrs, then fixup is placed just after .got