[U-Boot-Users] [PATCH] Off-by-two bug when relocating GOT

[Vlad Lungu <vlad@comsys.ro>]

Shinya Kuribayashi wrote:
[snip]

> Here's my proposal for RFC. This patch fixes
>   
> 1) __got_start and _GLOBAL_OFFSET_TABLE_ miss-alignment, and
>   
> 2) duplicated .sdata declaration.
>   
[snip]
>   
> +       .got : {
>   
> +               _gp = .;
>   
> +               __got_start = .;
>   
> +               *(.got)
>   
> +               __got_end = .;
>   
> +       }
[snip]
That doesn't look right.  Don't put _gp inside .got section.
>   
> I think this style is easier to understand than before.
>   
> But I'm still wondering where _gp can be used?
>   
> Any comments are welcome.
>   
>   

It should be loaded into the $gp register.

> got[0](=0x00000000) and got[1](=0x80000000) are always reserved by
>   
> GNU ld. When updating the contents of GOT entries at in_ram:, leave
>   
> first two entries as they are. This is the reason for skipping two
>   
> entries. And as you know, this is nothing related with corrupting
>   
> command table. That's caused by relocation itself, not by updating
>   
> GOT entries.
>   
>   
.got it :-)
>> One more point: loading  $gp with _GLOBAL_OFFSET_TABLE_ is not a good  
>> idea, it should be loaded with _gp. The value
>>     
>> is the same at the moment, but it's not guaranteed at all, someone could 
>> start playing with the link scripts and break this.
>>     
> Hmm, I have to consider more.
>   

Here's a good example:

http://www.sourceware.org/ml/ecos-discuss/2004-02/msg00327.html

There are some sections (.sdata/.sbss/.scommon)  that contain objects referenced via $gp and not via GOT.

Try nm -n -f sysv u-boot|grep scommon. 

I can also send you a patch with _gp != __got_start , and if you don't 
load $gp with _gp but with __got_start, it will crash and
burn when doing

       /* Initialize any external memory.
         */
        la      t9, lowlevel_init
        jalr    t9


It will actually jump to _serial_puts(), believe it or not.

Vlad