[Cbe-oss-dev] memalign weirdness in newlib

[Patrick Mansfield]

Michael -

On Mon, Dec 24, 2007 at 01:53:55PM +1100, Paul Mackerras wrote:
> Michael Ellerman writes:
> 
> > [michael at schoenaich bug]$ elfspe memalign
> > align = 0x10 p = 0x1c20 q = 0x2e20
> > align = 0x20 p = 0x3e20 q = 0x4e60
> > align = 0x30 p = 0x5ec0 q = 0x5ec0
> > align = 0x40 p = 0x5ec0 q = 0x5ec0
> > align = 0x50 p = 0x5ef0 q = 0x5ef0
> > align = 0x60 p = 0x5f00 q = 0x5f00
> > align = 0x70 p = 0x5f00 q = 0x5f00
> > align = 0x80 p = 0x5f00 q = 0x5f00
> > 
> > For alignments > 0x20 successive calls to memalign() return the same
> > memory? Or am I going crazy.
> 
> The alignment has to be a power of 2, so I imagine you're invoking
> undefined behaviour for the 0x30, 0x50, 0x60 and 0x70 cases.

Also the memalign() in SDK 3.0 (spu-newlib-1.15.0-82) has a bug: it will
call the standard malloc() for allocations, but then if you call free() it
will call the SPU specific free(), and that can lead to problems. If you
don't call free() it should work OK.

I am/was working on a fix. The bug is not in current mainline newlib code,
the RFC patch I posted to newlib has quite a lot of changes from the SPU
malloc in SDK 3.0, with that patch it does not eveny supply a memalign().

Patch:

http://sourceware.org/ml/newlib/2007/msg01029.html

-- Patrick Mansfield