Re: gcc on OSR5 status. was: bootstraps broken during last 24 hours

[Robert Lipe <robertlipe at usa dot net>]

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
/dev/zero.

So I have had an #undef MAP_ANONYMOUS in my copy of ggc-page.c for some
time.

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

RJL