[U-Boot] [Question] [ARM] global data array defined in board.c linkage problem : overlapping with relocation sections

[Sun Eric]

Hi all,

Today I have some new findings on this topic.

In "arch/arm/cpu/u-boot.lds", the BSS section is arranged as the following

---------------------------------------------------
    .bss __rel_dyn_start (OVERLAY) : {
        __bss_start = .;
        *(.bss)
         . = ALIGN(4);
        __bss_end__ = .;
    }
---------------------------------------------------

That is, the BSS section is re-using the ".rel.dyn" section. So that's
explains why my global array corrupts the relocation table when defined in
board.c while not when defined in bootp.c. In the final link stage, board.o
is first linked while bootp.o is linker quite late. So the array location
is in located in different place in the final target, as shown in the
following figure.

+-----------+-----------+
|           |           | <--- 1. array location when defined in "board.c"
| .rel.dyn  |           |
|           |           |
+-----------+   .bss    |
            |           |
            |           | <--- 2. array location when defined in "bootp.c"
            |           |
            +-----------+

As can be seen, situation (1) will corrupt relocation table, while
situation (2) won't.

This brings some further concern, a global data may or may not corrupt
relocation table, and it is quite random. So why in the first place we
overlay .bss with .rel.dyn?

Regards,
Eric


On Tue, Sep 11, 2012 at 3:06 PM, Sun Eric <ericsunplus at gmail.com> wrote:

> Hi all,
>
> Recently I tried to bring up a new platform with the latest U-Boot code
> (the git hash is e66443f). For recording some info before UART becomes
> functional, I added a circular array in "arch/arm/lib/board.c", together
> with some "printf" like function which simply write the debug string to the
> array.
>
> Things works fine until the code goes to "relocate_code()", the
> "copy_loop" is finished but once the code goes to "fixloop", quite soon the
> code will attempt to write to some invalid address, then the system will
> hang.
>
> Further debugging shows that the root cause is that, the circular array I
> added in board.c is linked to some address which in between
> "__rel_dyn_start" and "__rel_dyn_end". Originally the area contains all
> relocation section entries, which has the format " address_to_fix 0x17
> address_to_fix 0x17 ....". Now for some reason the linker put the circular
> array here, and write to this circular array will overwrite it with some
> random data, thus later "address fix" algorithm will easily write to
> invalid address.
>
> On the other hand, this issue seems only happen to board.c. If I
> experimentally add it to another file, say "net/bootp.c". The linkage
> becomes correct, the array is linked to BSS section which is after
> "__rel_dyn_end". I looked at the build log, and don't find a difference on
> how "board.o" and "bootp.o" is linked to the final u-boot elf file. So I
> can't understand why the final linkage result is different.
>
> Can someone please help me out?
>
> The array I added is as the following:
> -----------------------------------------------------------
> static uchar local_log_buf[LOCAL_BUF_SIZE] = {0};
> static ushort local_log_buf_index = 0;
>
> static void initlocalbuf(void) {...}
> void writelocalbuf(char* fmt, ...) {...}
> void dumplocalbuf(void) {...}
> -----------------------------------------------------------
>
> Regards,
> Eric
>
>
>