This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: [Cbe-oss-dev] memalign weirdness in newlib
- From: Patrick Mansfield <patmans at us dot ibm dot com>
- To: Michael Ellerman <michael at ellerman dot id dot au>, newlib at sourceware dot org
- Cc: Paul Mackerras <paulus at samba dot org>, cbe-oss-dev <cbe-oss-dev at ozlabs dot org>
- Date: Mon, 7 Jan 2008 09:09:09 -0800
- Subject: Re: [Cbe-oss-dev] memalign weirdness in newlib
- References: <1198464450.7162.5.camel@concordia> <18287.8003.668138.904469@cargo.ozlabs.ibm.com> <1199491152.6901.3.camel@concordia>
[adding newlib list ...]
On Sat, Jan 05, 2008 at 10:59:12AM +1100, Michael Ellerman wrote:
> 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@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).
I am still working on memalign for the SPU specific malloc (a different
problem, and not a bug in mainline newlib).
I failed so far trying to build newlib for ppc with linux (using Fedora
8), does anyone have build info for that (configure and make options)?
-- Patrick Mansfield