This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Replacing DejaGNU
- From: Iain Sandoe <idsandoe at googlemail dot com>
- To: MCC CS <mcccs at gmx dot com>
- Cc: gcc at gcc dot gnu dot org, Rainer Orth <ro at CeBiTec dot Uni-Bielefeld dot DE>
- Date: Mon, 14 Jan 2019 14:30:22 +0000
- Subject: Re: Replacing DejaGNU
- References: <trinity-a2a7e429-292d-455f-9dc1-c97e201b66d4-1547473447594@3c-app-mailcom-bs12> <yddef9fbb0q.fsf@CeBiTec.Uni-Bielefeld.DE>
> On 14 Jan 2019, at 13:53, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote:
>
> "MCC CS" <mcccs@gmx.com> writes:
>
>> I've been running the testsuite on my macOS, on which
>> it is especially unbearable. I want to (at least try to)
>
> that problem may well be macOS specific: since at least macOS 10.13
> (maybe even 10.12; cannot currently tell for certain) make -jN check
> times on my Mac mini skyrocketed with between 60 and 80% system time.
> It seems this is due to lock contention on one specific kernel lock, but
> I haven't been able to find out more yet.
this PR mentions the compilation, but it’ even more apparent on test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84257
* Assuming SIP is disabled.
Some testing suggests that each DYLD_LIBRARY_PATH entry adds around 2ms to each exe launch.
So .. when you’re doing something that’s a lot of work per launch, not much is seen - but when you’re doing things with a huge number of exe launches - e.g. configuring or running the test suite, it bites.
A work-around is to remove the RPATH_ENVAR variable setting in the top level Makefile.in (which actually has the same effect as running things with SIP enabled)
=== Possible solution (partial hacks locally, not ready for posting)
My current investigations (targeted at GCC 10 time frame, even if they are subsequently back-ported) is to replace all use of absolute pathnames in GCC libraries with @rpath/xxx and figure out a way to get the compiler to auto-add the relevant rpaths to exes (so that a fixed installation of GCC behaves the same way as it does currently).
=== DejaGNU on macOS...
DejaGNU / expect are not fantastic on macOS, even given the comments above - it’s true. Writing an interpreter/funnel for the testsuite has crossed my mind more than once.
However, I suspect it’s a large job, and it might be more worth investing any available effort in debugging the slowness in expect/dejaGNU - especially the lock contention that Rainer mentions.
> There's no such problem on other targets, not even e.g. on Mac OS X 10.7.
indeed.
Iain