[Cbe-oss-dev] memalign weirdness in newlib

[Michael Ellerman]

On Mon, 2007-12-24 at 13:53 +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.

Yeah you're right, that was a stupid test case I whipped up, here's a
fixed version:

int main(uint64_t spe_id, uint64_t data, uint64_t env)
{
        void *p, *q;
        int i;

        for (i = 0x10; i < 0x90; i *= 2) {
                p = memalign(i, 0x1000);
                q = memalign(i, 0x1000);
                printf("align = 0x%x p = %p q = %p\n", i, p, q);
        }

        return 0;
}

And the output:

[michael at schoenaich bug]$ ./memalign 
align = 0x10 p = 0x1c20 q = 0x2e20
align = 0x20 p = 0x3e20 q = 0x4e60
align = 0x40 p = 0x5ec0 q = 0x5ec0
align = 0x80 p = 0x5f00 q = 0x5f00


Which is still broken AFAICT, for alignments > 0x20.

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/cbe-oss-dev/attachments/20080105/9a1a0d5f/attachment.pgp>