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

[Albert ARIBAUD]

Hi Graeme,

Le 29/02/2012 23:41, Graeme Russ a écrit :
> 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

ARMs relocate and don't have a valid BSS until board_init_r() but 
require gd as early as board_init_f().

> Regards,
>
> Graeme

Amicalement,
-- 
Albert.