[Cbe-oss-dev] memalign weirdness in newlib

[Michael Ellerman]

On Mon, 2008-01-07 at 11:22 -0800, Patrick Mansfield wrote:
> On Mon, Jan 07, 2008 at 01:47:44PM -0500, Jeff Johnston wrote:
> > Patrick Mansfield wrote:
> 
> >>> [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.
> >>
> >> 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 :-/

If only you were using a revision control system .. :P

> 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

That looks better :)

Is there any doco on building newlib for cell, and how to get the
compiler to use a custom built version?

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/20080108/4dee241a/attachment.pgp>