[Cbe-oss-dev] memalign weirdness in newlib

[Patrick Mansfield]

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

> > 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 :-/

I'm not sure what happened in my original testing of the base newlib where
I hit a failure, my view might have been messed or my testing was bad, I
did *not* hit any failures using older mainline newlib source.

> 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.

Ends up this is the same problem I posted on earlier: 

In our SDK 3.x (not in mainline newlib), there is a new SPU malloc, but a
corresponding memalign was not supplied. Calling memalign() calls the
standard memalign(), it in turn calls SPU malloc *and* free (previously
I'd thought only the SPU free was being called), since memalign() mucks
with internal data structures, that is very bad :-/

With modified code I'm working on (to be posted and pushed to mainline
newlib) I'm using the -DMALLOC_PROVIDED flag so none of the standard
malloc files are supplied, and I'm working on adding a proper memalign().

-- Patrick Mansfield