On Mon, Jun 17, 2019 at 2:46 PM David Taylor <[email protected]> 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 <[email protected]> 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
