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.tay...@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
