[U-Boot] ARM relocation, question to Heiko

[Graeme Russ <graeme.russ@gmail.com>]

On 04/10/10 19:28, Albert ARIBAUD wrote:
> Le 04/10/2010 09:27, Reinhard Meyer a ?crit :
>> Dear Albert ARIBAUD,
>>>
>>> Right now I can build (not run, mind you) u-boot for edminiv2 without
>>> -fPIC/-fPIE, with -pie and a modified u-boot.lds and start.S. Almost all

Any reason to do it in assembler? Have a look at arch/i386/lib/board.c
board_init_f() (especially if you apply my latest patch series)

>>> of the .rel.dyn fixup entries are type 23, that is, relative to the base
>>> address, which is good. However, here are about ten at the end which are
>>> type 2 -- symbol-relative -- and I am studying them in order to see if
>>> they are needed.

Hmm, for x86 they are all type 8 (R_386_RELATIVE) which are a simple Base +
Addend (B + A) entries

Type 23 is R_ARM_RELATIVE which are also B + A (although they can also by S
+ A whatever that means)

>>> If type 23 relocations are all that is needed, then a first ARM ELF
>>> relocation implementation should 'simply' trade GOT vs .rel.dyn
>>> relocation in start.S (I am almost there) and remove fixups in

Removing fixups - sweet, oh so sweet ;)

>>> board_init_r. Start.S would apply type 23 fixups only and ignore the
>>> rest. Later on we could add a build stage to rewrite the .rel.dyn
>>> section as suggested, by filtering out non-type-23 relocs and keeping
>>> only the address part of type-23 ones, reducing the .rel.dyn table
>>> roughly by half.

Also non type-8 for x86 - If all arches reduce down to a single relocation
type in .rel.dyn then we can ignore the type and simply strip all the
'type' fields.

[snip]
> 
>> A rather wild, but quite arch independant additional "build stage" for
>> relocation would be to link u-boot for two different TEXT_BASE values
>> e.g. TEXT_BASE (as desired) and TEXT_BASE+0x00010010. A special "diff"
>> tool should find the 32 bit places where relocation is required and
>> add a table to the end of u-boot.bin... (Just a rough idea)

I don't think we need to - everything should be handled by .rel.dyn. I
wrote a diff tool to do as you suggest, but I have no need for it now

Looks like we could be onto a winner :)

Regards,

Graeme