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

[Mike Frysinger]

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.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120229/8b14858d/attachment.pgp>