This is the mail archive of the
mailing list for the GCC project.
Re: gcc on OSR5 status. was: bootstraps broken during last 24 hours
Zack Weinberg wrote:
> leaks memory, depending on which version you have), I'd appreciate
> more info on this problem, so I can fix it at the same time.
I haven't checked the tree lately, but the underlying problem was that
on the -udk target when running on openserver, we see the #define for
MAP_ANONYMOUS and try to use it. Unfortunately, when running on an
OpenServer system, mmap doesn't support MAP_ANONYMOUS. (An identical
binary running on a UnixWare system will. It's just the underlying
system calls that differ.
A peer suggested testing this at runtime and caching the answer. If
MAP_ANONYMOUS fails, cache that failure and fall back to the mmap of
So I have had an #undef MAP_ANONYMOUS in my copy of ggc-page.c for some
> - we do mmap(NULL, size, READ/WRITE, MAP_ANON, -1, 0) if we think we
> have MAP_ANON. -1 is the file descriptor argument. What does -udk
> do when handed this?
There isn't a MAP_ANON, only a MAP_ANONYMOUS
> - Is MAP_ANONYMOUS also defined, and does *that* work in this context?
I think it returns a MMAP_FAILED.
> - Is there a different, functional way to use MAP_ANON(YMOUS) on -udk?
I don't think so. John, do you know?
> - Can we do instead
> mmap(NULL, size, READ/WRITE, MAP_PRIVATE, /dev/zero, 0) ?
Yes, that works and that's the fallback I think we're falling into
when I #undef MAP_ANONYMOUS.
Now, with all of that typing done I just removed the #undef and cranked
a bootstrap on UDK. Seems to work. I can't explain the difference.