Re: [Cbe-oss-dev] memalign weirdness in newlib

[Patrick Mansfield <patmans at us dot ibm dot com>]

On Mon, Jan 07, 2008 at 01:47:44PM -0500, Jeff Johnston wrote:
> Patrick Mansfield wrote:

>>> [michael@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.
>>
>> Looks like a newlib bug.
>>
>> I tried your test case with mainline newlib, and get similar results, I
>> only tried for SPU (CELL).

> The test works fine for two 1.16.0 newlib local builds on my system 
> (i686-linux-pc-gnu and mn10300-elf).
>
> Could you debug further and isolate what is being passed to malloc, what is 
> being passed to the low-level syscall, and finally what is being returned?

I was testing with a mainline newlib cvs snapshot from about two months
ago, I switched to curent cvs (as of now), and did not hit the problem.

I will look for the fix/change ... I wish I'd left my old view intact :-/

Off the top of my head, I don't know of anything SPU specific that wasn't
in the earlier newlib source. There was an sbrk() change but that is
already in the build Michael is using, and that would only lead to a
malloc() failure, not a bad result.

Results with mainline newlib current snapshot:

[elm3a225 test]$ ./fail-memalign-base
align = 0x10 p = 0x2e30 q = 0x3e40
align = 0x20 p = 0x4e60 q = 0x5e80
align = 0x40 p = 0x6ec0 q = 0x7f00
align = 0x80 p = 0x8f80 q = 0xa000

-- Patrick Mansfield