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

[J. William Campbell <jwilliamcampbell@comcast.net>]

Joakim Tjernlund wrote:
>> On Wed, Oct 7, 2009 at 5:55 PM, Wolfgang Denk <wd@denx.de> wrote:
>>     
>>> Dear Graeme Russ,
>>>
>>> In message <d66caabb0910061824s4165d33bu5d5213f6783c09d0@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
>
>
>   
There is also a trade-off in using the -mrelocatable / .fixup method 
that should be considered in the general case. -fPIC or even -fpic code 
is almost always larger than the code generated for -mrelocateable, so 
it it the final size of the object blob in prom that matters, not just 
the length of the fixup segment. This effect is architecture dependent, 
where PIC is much cheaper on a PPC than on an Intel 386. So the "best" 
combination may depend on the chip.
I would also strongly encourage the -mrelocateable method be always 
available as an option. Historically, -fPIC has been buggy in initial 
releases of GCC for new architectures, probably because you can do 
useful work with just relocateable code and PIC can come "later". So it 
may be that u-boot would need an -mrelocateable approach for some period 
until -fPIC/-fpic worked. In any case, it would be a good fallback if 
one suspected a bug in PIC.

Best Regards,
Bill Campbell