Hi Frank,
>> > * Some tests were failing while calling unregister in munmap. It turned
>> > out that there had been no corresponding mmap registration before.
>> > This occurs because Solaris has mmap64 for largefile-aware programs
>> > instead. Fixed by wrapping mmap64, too. What I don't know is if
>> > mmap64 needs to be added to MFWRAP_SPEC in gcc.c?
>
> I believe so.
ok, though I haven't seen a failure so far without.
>> > If so, I'd rather do it by adding some MFWRAP_OS_SPEC to avoid
>> > having to duplicate the whole spec in the Solaris config
>> > headers.
>
> Why would solaris have to duplicate MFWRAP_SPEC if mmap64 is added to
> the default gcc.c one?
I assumed that you wanted to keep the default generic, and meant to
separate target specific additions from the generic part.
>> > * libmudflap.c/heap-scalestress.c always timed out on my SPARC test
>> > system: on a 1.2 GHz UltraSPARC-T2, it takes
>> >
>> > real 8:47.06
>> > user 43.12
>> > sys 8:03.77
>> >
>> > which is way over the limit. On my laptop (1.6 GHz Core i7), it takes
>> >
>> > real 37.35
>> > user 5.06
>> > sys 32.23
>> >
>> > I've divided SCALE by 10 to account for this.
>
> OK; I'm surprised by the order-of-magnitude performance difference
> between the machines though.
Right: though the Niagara CPUs are slow, I hadn't expected that much
either.
So if you agree, I can add mmap64 to the default MFWRAP_SPEC. All other
parts are approved, I think.
In the meantime, I've rebuild and re-tested on Solaris 11/x86, too.
While the gld results are as good as on SPARC, I still get several
failures with Sun ld (which works fine on SPARC). I haven't analyzed
them yet.
I could either commit the current version with the MFWRAP_SPEC addition
and work from there, or wait until those failures are understood and
fixed, too.
Thanks.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
