[U-Boot] memory corruption on nios2 due to overlap of gbl data and malloc

[Graeme Russ]

Hi Mike,

On Thu, Mar 1, 2012 at 9:29 AM, Mike Frysinger <vapier at gentoo.org> wrote:
> On Wednesday 29 February 2012 17:22:26 Graeme Russ wrote:
>> On Thu, Mar 1, 2012 at 6:04 AM, Mike Frysinger wrote:
>> > On Tuesday 28 February 2012 18:32:57 Graeme Russ wrote:
>> >> And this is why I dislike the implementation - You have to do all sorts
>> >> of weird calucations to put things in the right place when, in fact,
>> >> the location of gd and bd in memory is totally irrelavent.
>> >
>> > right, that's why i minimized the pain for Blackfin users -- this is all
>> > handled in the arch's config-pre.h header.  board porters only need to
>> > declare the size of regions they care about (monitor and heap sizes).
>> >
>> >> Ow, ouch! - And that padding makes things more fun - The memory layout
>> >> is
>> >>
>> >> U-Boot | gd | pad | bd | pad | heap
>> >
>> > fwiw, i documented the Blackfin memory layout:
>> > http://docs.blackfin.uclinux.org/doku.php?id=bootloaders:u-boot:memory-la
>> > yout
>>
>> I had a look at this and noticed that you statically allocate locations for
>> gd and bd (CONFIG_SYS_GBL_DATA_ADDR, CONFIG_SYS_BD_INFO_ADDR)
>>
>> Considering that:
>>
>> a) the gd pointer is in a register (P3) and thus easily locatable by a
>>    debugger, and;
>> b) the bd pointer is in gd
>>
>> Is there any reason not to have gd and bd in BSS?
>
> in the Blackfin case, most likely not.  we don't do relocation, and the bss is
> cleared long before board_init_f() gets called.  the only reason for allowing
> the config to override would be if someone wanted to put gd/bd into on-chip L1
> data, but i can't imagine this structure being performance critical enough to
> warrant that.

I thought as much - I moved gd/bd into BSS for x86 without really thinking
about why everyone else calculates the location of these data structures
around the stack and heap. The longer I think about it, the more I think
that it was not a bad move and that maybe other arches can follow suit as
part of standardising the init sequences

Regards,

Graeme