Re: gcc: -ftest-coverage and -auxbase

[David Taylor <dtaylor at emc dot com>]

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 <richard dot guenther at gmail dot com>
    Date: Thu, 13 Jun 2019 10:22:54 +0200

    ------------------------------------------------------------------------

    On Wed, Jun 12, 2019 at 10:17 PM <David.Taylor@dell.com> 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
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/<product-name>/some/dir/path.o.d \
    more than a dozen '-iquote <some-relative-directory>' 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/<product-name>/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