> From: Richard Biener <richard.guent...@gmail.com>
> Sent: Monday, June 17, 2019 9:57 AM
> To: taylor, david
> Cc: GCC Development
> Subject: Re: gcc: -ftest-coverage and -auxbase
> On Mon, Jun 17, 2019 at 2:46 PM David Taylor <dtay...@emc.com> wrote:
> >
> > 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
>
> -o -
>
> you mean. OK, so the issue is that with -o - auxbase is computed in a not so
Right. Sorry for the brain fart.
> 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.
The build tree is laid out the same as the source tree...
rel/a/tive/path.c is compiled into some-prefix/rel/a/tive/path.c
But I was certainly hoping / expecting that setting auxbase would cause the
proper information to be recorded in the assembly file so that everything would
be found.
I should have thought to check the spec strings. Given that the common.opt
file marks it as RejectDriver, it pretty much a given
that when it needs to be set the driver is not going to check if it
is already set...
How about, instead of a new specs letter with a new meaning,
instead just wrap {!auxbase ... } around the current setting?
It seems that that combined with removing RejectDriver would
solve the problem.
> Using -pipe would also work so why not use that together with -Wa,... for the
> assembler options you need?
I'll have to see if the build can be twisted into doing that.
Currently there are three scripts that optionally run between the compiler and
the assembler. When they run they collect information into a 'side file' for
additional processing later.
The .c to .o rule is already fairly complicated... I am loathe to
make it more complicated.
> > 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.
