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

[Graeme Russ]

On Wed, Oct 7, 2009 at 11:09 AM, Peter Tyser <ptyser at xes-inc.com> wrote:
> On Tue, 2009-10-06 at 18:43 -0500, Peter Tyser wrote:
>> > > The values all changed and are dependent on RAM size, but their
>> > > relationship to one another didn't - they all just increased by
>> > > 0x7fff0000.  So practically speaking, we do need to know where the bss
>> > > is at link time - its address is not dynamic like the malloc pool or
>> > > stack - its tied directly to the address of the other sections at link
>> > > time.  (Unless we added some bss-specific fixups I imagine)
>> >
>> > Right, that's the current situation.
>> >
>> > My suggestion was NOT to put the bss  at  a  fixed  _offset_  to  the
>> > U-Boot  image,  but to a fixed absolute address. My hope is that this
>> > might simplify the linker scripts at the cost of adding a little code
>> > to the relocation routine - for addresses in the bss we would have to
>> > add a different relocation offset.
>>
>> I think I see what you're getting at.  If we have a bss-specific fixup
>> routine I don't give a hoot where the bss is located at link time.  Its
>> just that that bss-aware fixup routine doesn't exist right now:)
>>
>> It seems like a clean solution.  Adding a bss-aware fixup routine or
>> putting the bss after the U-Boot image both seem good to me.  The
>> bss-aware fixup routine has a clearer readelf output and slightly more
>> complicated code while the bss-after-uboot change has a misleading
>> readelf output and simpler code.  In any case I'd give a thumbs up to
>> either of them.
>
> Sorry, just to be clear, where did you want to put the fixed up bss?
> Still at a low memory address, ie the original address at link time?  I
> had assumed if we were adding a bss-specific fixup we'd move it to the
> top of memory, near U-Boot, the malloc pool, etc.  I'd be all for
> relocating it to higher in memory, but wouldn't be too excited about
> leaving at a low memory address...  If we were to add bss fixups, we may
> as well move it to a location that lines up with the rest of U-Boot
> code, stack, and malloc, right?
>
> Best,
> Peter
>

The longer this thread goes on, the more obvious it becomes to me that a
basic dynamic loader which is 'ELF Aware' will overcome most (if not
ultimately all) of the problems being discussed in relation to relocation.

I have a proof-of-concept for this (written entirely in C) which I needed
to create due to the lack of a .fixup section on my arch (a limitation of
all but one arch to date). More to the point, the information regarding the
content of the ELF sections I was able to find wasn't even for the target
arch I wrote the code for - It is all very generic (to a point).

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.

I believe that relocation for all arches, and thus the permanent removal
of all the relocation fix ups littering the code, can be achieved far
quicker this way.

Regards,

Graeme