Re: gcc: -ftest-coverage and -auxbase

[Richard Biener <richard.guenther@gmail.com>]

On Mon, Jun 17, 2019 at 2:46 PM David Taylor <dtaylor@emc.com> 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 <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

-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 %<take-free-letter> 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/<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