From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32636 invoked by alias); 17 Jun 2019 13:56:56 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 32627 invoked by uid 89); 17 Jun 2019 13:56:56 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,GIT_PATCH_2,RCVD_IN_DNSWL_NONE,SPF_PASS,UNSUBSCRIBE_BODY autolearn=ham version=3.3.1 spammy=assemble, arrived, GAS, controlled X-HELO: mail-lj1-f169.google.com Received: from mail-lj1-f169.google.com (HELO mail-lj1-f169.google.com) (209.85.208.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 17 Jun 2019 13:56:54 +0000 Received: by mail-lj1-f169.google.com with SMTP id 131so9416132ljf.4 for ; Mon, 17 Jun 2019 06:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=24yWevRcTG4ZZK3Dkp19bdLQCAKwxkmVj6XcPekFlXU=; b=Tp83CdJ6Qakmc9GrmKBP4NCdWy+arer45/oo02l9VUNKMgAVQNK11xcKGT+GyJLkBZ Fw6TiOJA4KPnNzh3ad6JDdseMOh2tsemIs7JJSBRfZtRGe1UvPJ+u34DUxnrri2VM6PA YvOIYuVJsaNfPpDXUS3tX975U+wuUHj0E7QsPM7I5rIvbxE8dfDsQYn0F2Hai8dAzVEC d44PZKXatQNAqF7+flkm05Q+q3OSFIz4VucrvNFjSrkXbQ+fjUHoey0gvnwf0/v8hMa+ Mnyo3lEimNOwhyl+UFmIvprzRucmAuRYvNGoc1cpsWPkTtneg/ojdde/P3/u32oHOoeD Fepg== MIME-Version: 1.0 References: <12454.1560775576@usendtaylorx2l> In-Reply-To: <12454.1560775576@usendtaylorx2l> From: Richard Biener Date: Mon, 17 Jun 2019 13:56:00 -0000 Message-ID: Subject: Re: gcc: -ftest-coverage and -auxbase To: David Taylor Cc: GCC Development Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-06/txt/msg00160.txt.bz2 On Mon, Jun 17, 2019 at 2:46 PM David Taylor wrote: > > Sorry for the late reply. Your message never arrived in my mailbox. > I suspect that corporate email has swallowed it for some stupid > reason. I'm replying to a copy I found in the mailing list archives > at gcc dot gnu dot org. Hopefully I didn't screw up the editing. > > From: Richard Biener > Date: Thu, 13 Jun 2019 10:22:54 +0200 > > ------------------------------------------------------------------------ > > On Wed, Jun 12, 2019 at 10:17 PM wrote: > > > > When doing a build, we use a pipe between GCC and GAS. > > And because we wish to do some analysis of the assembly code, > > we do not use -pipe but instead do '-S -c -'. And this has worked > > fine for many years. > > Can you please show us complete command-lines here? -S -c - > will only assemble (and require source from standard input > and produce output in -.s). > > Actually, GCC recognzes '-c -' as meaning to write to stdout. The *.c -o - you mean. OK, so the issue is that with -o - auxbase is computed in a not so useful way from %{!fcompare-debug-second:%{c|S:%{o*:-auxbase-strip %*}%{!o*:-auxbase %b}}}%{!c:%{!S:-auxbase %b}} which means we just pass '-auxbase-strip -', I guess in this case the !o choice of using %b (substitute the basename of the input file) is a more sensible choice. That means having a new spec % expanding to %* when it is not - and else expand to %b (which might be stdin, also not useful). Note that the coverage utility might not be able to find the output file then. Using -pipe would also work so why not use that together with -Wa,... for the assembler options you need? > file is given on the command line to GCC. And the output of GAS is > specified with -o. > > The compile & assemble part of the command line is approximately 2K > bytes in length. Mostly it's pretty boring. It's roughly: > > /full/path/to/version/controlled/gcc \ > -MMD -MF bin//some/dir/path.o.d \ > more than a dozen '-iquote ' combos \ > some -D switches \ > some -imacros switches \ > -pipe \ > more than a dozen -f switches \ > -Wall -Werror and about two dozen additional -W switches \ > some -m switches \ > -gdwarf-4 -g3 \ > -S -o - some/dir/path.c \ > | > /full/path/to/version/controlled/as \ > -warn-fatal-warnings -64 > bin//some/dir/path.o_ > > On success the *.o_ file will be renamed to *.o in the same directory. > > Dozen products each built on a different machine (whichever dozen > build cluster machines are currently the most lightly loaded). > > Each sub-build is done by a GNU make with either a '-j 64' or '-j 128'. > > Currently all the compiles write to the same GCNO file. Not very > useful. If -auxbase was not just passed to sub-processes but actually > user settable, I believe that the problem would disappear... > > Ignoring documentation (it's needed and important, but I haven't > thought about what to say as yet), I believe that this would be a > one-line change to common.opt and nothing more. > > > I was recently looking into collecting some coverage information. > > To that end, I added --coverage to the invocation line. And it slowed > > things down by more than an order of magnitude! > > > > Investigating, it appears that the problem is the writing of the GCNO > > files. > > > > We do our builds on a build cluster with a lot of parallelism. > > With the result that a dozen machines are each doing a bunch > > of writes to the file '-.gcno' in an NFS mounted directory. > > > > Rather than have a full, not incremental, build take 5-10 minutes, > > It takes 4 hours. And rather than have each of several thousand > > compiles produce their own GCNO file, they all get overwritten... > > > > Grep'ing around, I found '-auxbase'. If I correctly understand it, > > when compiling > > > > some/path/name.c > > > > into > > > > bin/some-product/some/path/name.o, > > > > I could simply say > > > > -auxbase $(@:%.o=%) > > > > The problem is that in common.opt, auxbase is marked RejectDriver. > > > > It looks like removing it would some my problem. Anyone have a reason > > why removing that would be a bad idea? Or have a different solution? > > > > Thanks. > > > > David