[U-Boot] [RFC] [PATCH V2] arm: arm926ejs: use ELF relocations

[Reinhard Meyer <u-boot@emk-elektronik.de>]

Dear Graeme Russ,
>> .globl _rel_dyn_start_ofs
>> _rel_dyn_start_ofs:
>> 	.word __rel_dyn_start - _start
>> .globl _rel_dyn_end_ofs
>> _rel_dyn_end_ofs:
>> 	.word __rel_dyn_end - _start
>> .globl _dynsym_start_ofs
>> _dynsym_start_ofs:
>> 	.word __dynsym_start - _start
>>
>> get the values to "C".
> 
> Odd, is x86 different:
> 
> extern ulong _i386boot_rel_dyn_start;
> extern ulong _i386boot_rel_dyn_end;
> 
> void board_init_f (ulong stack_limit)
> {
> ...
> 	Elf32_Rel *rel_dyn_start = (Elf32_Rel *)&_i386boot_rel_dyn_start;
> 	Elf32_Rel *rel_dyn_end = (Elf32_Rel *)&_i386boot_rel_dyn_end;
> ...

It can be done that way, too! But above assembly code provides
relative offsets already, in "C" it would turn a bit uglier ;)
(TODO later)

> Provided you only use local variables (i.e. stored on the stack) the code
> might be relocatable anyway (the jump from asm to C will hopefully be
> relative). If you run the code at another address you will need to
> calculate the load offset and adjust rel_dyn_start and rel_dyn_end
> accordingly (see recent x86 patch series)

Probably. That adjustment is inherent, since offsets are used!

> 
> [snip]
> 
>> Is an entry in _dynsym really 16 bytes long?

My Questions was that Albert shifts "r_info" 4 times (= divide by 16)
to index into the _dynsym table, implying dynsym has 16 byte entries.
I see that it has - in elf.h. OK

> 
> Yes, it is an Elf32_Rel struct - see include/elf.h in the U-Boot tree
> 
> typedef struct
> {
> 	Elf32_Addr	r_offset;	/* offset of relocation */
> 	Elf32_Word	r_info;		/* symbol table index and type */
> } Elf32_Rel;

I will use the struct now.

> 	/* Perform relocation adjustments */
> 	re_src = (Elf32_Rel *)(rel_dyn_start + ((gd_t *)gdp)->load_off);
> 	re_end = (Elf32_Rel *)(rel_dyn_end + ((gd_t *)gdp)->load_off);

Using relative offsets the loop is a bit different...

Reinhard