Re: gcc: -ftest-coverage and -auxbase

Re: gcc: -ftest-coverage and -auxbase

[David Taylor]

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

Re: gcc: -ftest-coverage and -auxbase

[Richard Biener]

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

RE: gcc: -ftest-coverage and -auxbase

[David.Taylor]

> From: Richard Biener <richard.guenther@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 <dtaylor@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.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

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.

Re: gcc: -ftest-coverage and -auxbase

[Richard Biener]

On Mon, Jun 17, 2019 at 5:02 PM <David.Taylor@dell.com> wrote:
>
> > From: Richard Biener <richard.guenther@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 <dtaylor@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.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
>
> 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.

You could also supply alternate specs, -dumpspecs gets you the default contents
which you can put into a file, edit out the problematic part (just
always use %b)
and supply it via -specs ...

I don't think we want to expose -auxbase.  Iff then an alternate way to specify
a coverage output file name.

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

Re: gcc: -ftest-coverage and -auxbase

[Martin Liška]

On 6/18/19 10:40 AM, Richard Biener wrote:
> I don't think we want to expose -auxbase.  Iff then an alternate way to specify
> a coverage output file name.

I'm not aware of it.

@David: Can you please summarize what you want to achieve with the .gcno files?
I can then help you.

Martin

RE: gcc: -ftest-coverage and -auxbase

[David.Taylor]

Dell Customer Communication - Confidential

> From: Martin Liška <mliska@suse.cz>
> Sent: Tuesday, June 18, 2019 4:56 AM
> 
> On 6/18/19 10:40 AM, Richard Biener wrote:
> > I don't think we want to expose -auxbase.  Iff then an alternate way
> > to specify a coverage output file name.
> 
> I'm not aware of it.
> 
> @David: Can you please summarize what you want to achieve with the .gcno
> files?
> I can then help you.
>
> Martin

Thanks.

Short answer:  Some of the GNU/Linux test coverage related tools
want them, so I want them to be available.

Longer answer:

We have purchased a third party tool for providing code test
coverage related information.  We do not plan to abandon that
tool as it provides more than just test coverage.  But, for test
coverage at least, I would like an alternative.  I am exploring the
use of GCC and related tools for this.

Our target is embedded, which presents a set of challenges.
The set up / tear down glue code will need to be written.
The operating system does not exit.  Data will be dumped via
a network connection, not to a local disk.  Coverage counters
need to be dumped and/or cleared on demand.

Additionally, since the system supports not just cold boot but
also warm boot, initialized .data is prohibited.  So, it will be
necessary to either put the data into a section with a different
name and/or (ideally, both) have run-time initialization.

[My gut is that adding a command line switch to set the section
name and finding the code that actually writes out the data to
make use of it won't be hard.  And that run-time initialization
will be significantly harder.]

I don't know the details of how the tools make use of the *.gcno
files, but I assume that they either need it or give better reports
if they have it.

I want people to be able to ascertain things like

. this file has excellent coverage

. this file has horrible coverage

. this pull request affected these lines in these files, and
  when the test suite was run these affected lines were covered,
  but these other affected lines were not covered.

. this push will affect these lines in these files, has my testing
  covered them?

I'm sure I left something out.  But, hopefully, you now have a
clearer idea of what I'm trying to achieve.  Questions?  Feel
free to ask.

I don't as yet have management buy in on this...

Re: gcc: -ftest-coverage and -auxbase

[Martin Liška]

On 6/18/19 3:31 PM, David.Taylor@dell.com wrote:
> Dell Customer Communication - Confidential
> 
>> From: Martin Liška <mliska@suse.cz>
>> Sent: Tuesday, June 18, 2019 4:56 AM
>>
>> On 6/18/19 10:40 AM, Richard Biener wrote:
>>> I don't think we want to expose -auxbase.  Iff then an alternate way
>>> to specify a coverage output file name.
>>
>> I'm not aware of it.
>>
>> @David: Can you please summarize what you want to achieve with the .gcno
>> files?
>> I can then help you.
>>
>> Martin
> 
> Thanks.
> 
> Short answer:  Some of the GNU/Linux test coverage related tools
> want them, so I want them to be available.
> 
> Longer answer:
> 
> We have purchased a third party tool for providing code test
> coverage related information.  We do not plan to abandon that
> tool as it provides more than just test coverage.  But, for test
> coverage at least, I would like an alternative.  I am exploring the
> use of GCC and related tools for this.
> 
> Our target is embedded, which presents a set of challenges.
> The set up / tear down glue code will need to be written.
> The operating system does not exit.  Data will be dumped via
> a network connection, not to a local disk.  Coverage counters
> need to be dumped and/or cleared on demand.
> 
> Additionally, since the system supports not just cold boot but
> also warm boot, initialized .data is prohibited.  So, it will be
> necessary to either put the data into a section with a different
> name and/or (ideally, both) have run-time initialization.
> 
> [My gut is that adding a command line switch to set the section
> name and finding the code that actually writes out the data to
> make use of it won't be hard.  And that run-time initialization
> will be significantly harder.]
> 
> I don't know the details of how the tools make use of the *.gcno
> files, but I assume that they either need it or give better reports
> if they have it.

.gcno files are created during compilation and contain info about a source file.
These files will be created by a cross compiler, so that's fine.

During a run of a program a .gcda file is created. It contains information about
number of execution of edges. These files are dumped during at_exit by an instrumented
application. And the content is stored to a disk (.gcda extension).

So what difficulties do you have with that please?

Martin

> 
> I want people to be able to ascertain things like
> 
> . this file has excellent coverage
> 
> . this file has horrible coverage
> 
> . this pull request affected these lines in these files, and
>   when the test suite was run these affected lines were covered,
>   but these other affected lines were not covered.
> 
> . this push will affect these lines in these files, has my testing
>   covered them?
> 
> I'm sure I left something out.  But, hopefully, you now have a
> clearer idea of what I'm trying to achieve.  Questions?  Feel
> free to ask.
> 
> I don't as yet have management buy in on this...
> 

RE: gcc: -ftest-coverage and -auxbase

[David.Taylor]

> From: Martin Liška <mliska@suse.cz>
> Sent: Tuesday, June 18, 2019 11:20 AM
> 
> .gcno files are created during compilation and contain info about a source file.
> These files will be created by a cross compiler, so that's fine.
> 
> During a run of a program a .gcda file is created. It contains information about
> number of execution of edges. These files are dumped during at_exit by an
> instrumented application. And the content is stored to a disk (.gcda
> extension).
> 
> So what difficulties do you have with that please?
> 
> Martin

Not sure I understand the question.

Conceptually I don't have any problems with the compiler
creating .gcno files at compile time and the program creating
.gcda files at run-time.

As far as the .gcda files go, exit is never called -- it's an embedded
operating system.  The kernel does not call exit.  Application
specific glue code will need to be written.  This is to be expected.
And is completely reasonable.

As far as the .gcno files go -- currently, while doing over 10,000
compiles GCC wants to write all the .gcno files to the same file
name in the same NFS mounted directory.  This is simultaneously
not useful and very very slow.

Down the road I'm going to want to make additional changes --
for example, putting the instrumentation data into a section
specified on the command line rather than .data.

Right now I'm concerned about the .gcno files.  I want to be
able to specify the pathname or the base of the pathname
on the command line.  I don't really care whether it is called
-auxbase or something else.  I was thinking '-auxbase' as that
is the name currently passed to the sub-processes.  I do not
ultimately care what the name is...

Additionally, if we do this I want it to be done in a manner
that when contributed back is likely to be accepted.

Re: gcc: -ftest-coverage and -auxbase

[Martin Liška]

[-- Attachment #1: Type: text/plain, Size: 2356 bytes --]

On 6/18/19 11:51 PM, David.Taylor@dell.com wrote:
>> From: Martin Liška <mliska@suse.cz>
>> Sent: Tuesday, June 18, 2019 11:20 AM
>>
>> .gcno files are created during compilation and contain info about a source file.
>> These files will be created by a cross compiler, so that's fine.
>>
>> During a run of a program a .gcda file is created. It contains information about
>> number of execution of edges. These files are dumped during at_exit by an
>> instrumented application. And the content is stored to a disk (.gcda
>> extension).
>>
>> So what difficulties do you have with that please?
>>
>> Martin
> 
> Not sure I understand the question.
> 
> Conceptually I don't have any problems with the compiler
> creating .gcno files at compile time and the program creating
> .gcda files at run-time.
> 
> As far as the .gcda files go, exit is never called -- it's an embedded
> operating system.  The kernel does not call exit.  Application
> specific glue code will need to be written.  This is to be expected.
> And is completely reasonable.

Yep, then call __gcov_dump at a place where you want to finish instrumentation:
https://gcc.gnu.org/onlinedocs/gcc/Gcov-and-Optimization.html

> 
> As far as the .gcno files go -- currently, while doing over 10,000
> compiles GCC wants to write all the .gcno files to the same file
> name in the same NFS mounted directory.  This is simultaneously
> not useful and very very slow.

Please take a look at attached patch, that will allow you to do:
./gcc/xgcc -Bgcc /tmp/main.c --coverage -fprofile-note-dir=/tmp/

$ ls -l /tmp/main.gcno
-rw-r--r-- 1 marxin users 228 Jun 19 09:18 /tmp/main.gcno

Is the suggested patch working for you?
Martin

> 
> Down the road I'm going to want to make additional changes --
> for example, putting the instrumentation data into a section
> specified on the command line rather than .data.
> 
> Right now I'm concerned about the .gcno files.  I want to be
> able to specify the pathname or the base of the pathname
> on the command line.  I don't really care whether it is called
> -auxbase or something else.  I was thinking '-auxbase' as that
> is the name currently passed to the sub-processes.  I do not
> ultimately care what the name is...
> 
> Additionally, if we do this I want it to be done in a manner
> that when contributed back is likely to be accepted.
> 
> 


[-- Attachment #2: fprofile-note-dir.patch --]
[-- Type: text/x-patch, Size: 1870 bytes --]

diff --git a/gcc/common.opt b/gcc/common.opt
index a1544d06824..d382e70317d 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2096,6 +2096,10 @@ Common Joined RejectNegative Var(profile_data_prefix)
 Set the top-level directory for storing the profile data.
 The default is 'pwd'.
 
+fprofile-note-dir=
+Common Joined RejectNegative Var(profile_note_prefix)
+Set the top-level directory for storing the profile note file.
+
 fprofile-correction
 Common Report Var(flag_profile_correction)
 Enable correction of flow inconsistent profile data input.
diff --git a/gcc/coverage.c b/gcc/coverage.c
index 1ffefd5f482..ea7b258d9dd 100644
--- a/gcc/coverage.c
+++ b/gcc/coverage.c
@@ -1204,6 +1204,12 @@ coverage_init (const char *filename)
   int len = strlen (filename);
   int prefix_len = 0;
 
+#if HAVE_DOS_BASED_FILE_SYSTEM
+  const char *separator = "\\";
+#else
+  const char *separator = "/";
+#endif
+
   /* Since coverage_init is invoked very early, before the pass
      manager, we need to set up the dumping explicitly. This is
      similar to the handling in finish_optimization_passes.  */
@@ -1217,11 +1223,6 @@ coverage_init (const char *filename)
 	 of filename in order to prevent file path clashing.  */
       if (profile_data_prefix)
 	{
-#if HAVE_DOS_BASED_FILE_SYSTEM
-	  const char *separator = "\\";
-#else
-	  const char *separator = "/";
-#endif
 	  filename = concat (getpwd (), separator, filename, NULL);
 	  filename = mangle_path (filename);
 	  len = strlen (filename);
@@ -1259,6 +1260,9 @@ coverage_init (const char *filename)
       memcpy (bbg_file_name, filename, len);
       strcpy (bbg_file_name + len, GCOV_NOTE_SUFFIX);
 
+      if (profile_note_prefix)
+	bbg_file_name = concat (profile_note_prefix, separator, bbg_file_name, NULL);
+
       if (!gcov_open (bbg_file_name, -1))
 	{
 	  error ("cannot open %s", bbg_file_name);

RE: gcc: -ftest-coverage and -auxbase

[David.Taylor]

Dell Customer Communication - Confidential

> From: Martin Liška <mliska@suse.cz>
> Sent: Wednesday, June 19, 2019 3:19 AM
> 
> On 6/18/19 11:51 PM, David.Taylor@dell.com wrote:
> >> From: Martin Liška <mliska@suse.cz>
> >> Sent: Tuesday, June 18, 2019 11:20 AM
> >>
> >> .gcno files are created during compilation and contain info about a source
> file.
> >> These files will be created by a cross compiler, so that's fine.
> >>
> >> During a run of a program a .gcda file is created. It contains
> >> information about number of execution of edges. These files are
> >> dumped during at_exit by an instrumented application. And the content
> >> is stored to a disk (.gcda extension).
> >>
> >> So what difficulties do you have with that please?
> >>
> >> Martin
> >
> > Not sure I understand the question.
> >
> > Conceptually I don't have any problems with the compiler creating
> > .gcno files at compile time and the program creating .gcda files at
> > run-time.
> >
> > As far as the .gcda files go, exit is never called -- it's an embedded
> > operating system.  The kernel does not call exit.  Application
> > specific glue code will need to be written.  This is to be expected.
> > And is completely reasonable.
> 
> Yep, then call __gcov_dump at a place where you want to finish
> instrumentation:
> https://gcc.gnu.org/onlinedocs/gcc/Gcov-and-Optimization.html
> 
> >
> > As far as the .gcno files go -- currently, while doing over 10,000
> > compiles GCC wants to write all the .gcno files to the same file name
> > in the same NFS mounted directory.  This is simultaneously not useful
> > and very very slow.
> 
> Please take a look at attached patch, that will allow you to do:
> ./gcc/xgcc -Bgcc /tmp/main.c --coverage -fprofile-note-dir=/tmp/
> 
> $ ls -l /tmp/main.gcno
> -rw-r--r-- 1 marxin users 228 Jun 19 09:18 /tmp/main.gcno
> 
> Is the suggested patch working for you?
> Martin
> 

Thanks for the patch.  Standalone it is not sufficient.  Combined
with the other two changes that have been discussed --

. allowing auxbase to be set and
. changing the specs to only set auxbase if it isn't already set

I think it might well solve the problem.

[Although if auxbase is allowed to be set I'm not convinced that
this patch is necessary.  If auxbase cannot be set, then this patch
alone is insufficient.]

We do all of our compiles from the top of the workspace.
There are a dozen different deliverables being built simultaneously.
There are over 3600 *.c files spread across over 200 directories.
Each deliverable is built by compiling and linking over 1000 of the
*.c files.  Overall over 16,000 compiles occur.  They are all done
from the top directory of the workspace.  And each deliverable
has its own set of compilation defines.  So, foo.o linked into one
deliverable may well be different from the foo.o linked into a
different one.  Further, the build tree structure mimics the
source tree structure.  So, you might well have two foo.o's
in different directories...

Our compilation lines combined with the current specs results
In GCC trying to create over 16,000 GCNO files all named -.gcno
and all living in the top level directory.

> > Down the road I'm going to want to make additional changes -- for
> > example, putting the instrumentation data into a section specified on
> > the command line rather than .data.
> >
> > Right now I'm concerned about the .gcno files.  I want to be able to
> > specify the pathname or the base of the pathname on the command line.
> > I don't really care whether it is called -auxbase or something else.
> > I was thinking '-auxbase' as that is the name currently passed to the
> > sub-processes.  I do not ultimately care what the name is...
> >
> > Additionally, if we do this I want it to be done in a manner that when
> > contributed back is likely to be accepted.
> >
> >

Re: gcc: -ftest-coverage and -auxbase

[Martin Liška]

On 6/19/19 7:11 PM, David.Taylor@dell.com wrote:
> Thanks for the patch.  Standalone it is not sufficient.  Combined
> with the other two changes that have been discussed --

Why is that not sufficient? If you build from top-level and you have .o files
that overwrite each other, then you can set -fprofile-note-dir=/tmp/my-unique-folder

And you'll not overwrite .gcno files.

Martin

RE: gcc: -ftest-coverage and -auxbase

[David.Taylor]

Dell Customer Communication - Confidential

> From: Martin Liška <mliska@suse.cz>
> Sent: Thursday, June 20, 2019 5:12 AM
> To: taylor, david; richard.guenther@gmail.com
> Cc: gcc@gcc.gnu.org
> Subject: Re: gcc: -ftest-coverage and -auxbase
> 
> On 6/19/19 7:11 PM, David.Taylor@dell.com wrote:
> > Thanks for the patch.  Standalone it is not sufficient.  Combined with
> > the other two changes that have been discussed --
> 
> Why is that not sufficient? If you build from top-level and you have .o files
> that overwrite each other, then you can set -fprofile-note-dir=/tmp/my-
> unique-folder
> 
> And you'll not overwrite .gcno files.
> 
> Martin

Right now GCC names the GCNO files '-.gcno'.

With your patch they get put into a specified directory.  But,
unless I am prepared to create over 16,000 directories each to
hold just one file (I'm not), it is not sufficient.

What I want to do -- unless it is going to create problems -- is
to place the notes files alongside the object files.  The files
foo.o and foo.gcno would be in the same directory.

Re: gcc: -ftest-coverage and -auxbase

[Thomas Koenig]

Am 20.06.19 um 15:00 schrieb David.Taylor@dell.com:
> Dell Customer Communication - Confidential

Can't expect me to read this, then? :-)

Re: gcc: -ftest-coverage and -auxbase

[Martin Liška]

On 6/20/19 3:00 PM, David.Taylor@dell.com wrote:
> Dell Customer Communication - Confidential
> 
>> From: Martin Liška <mliska@suse.cz>
>> Sent: Thursday, June 20, 2019 5:12 AM
>> To: taylor, david; richard.guenther@gmail.com
>> Cc: gcc@gcc.gnu.org
>> Subject: Re: gcc: -ftest-coverage and -auxbase
>>
>> On 6/19/19 7:11 PM, David.Taylor@dell.com wrote:
>>> Thanks for the patch.  Standalone it is not sufficient.  Combined with
>>> the other two changes that have been discussed --
>>
>> Why is that not sufficient? If you build from top-level and you have .o files
>> that overwrite each other, then you can set -fprofile-note-dir=/tmp/my-
>> unique-folder
>>
>> And you'll not overwrite .gcno files.
>>
>> Martin
> 
> Right now GCC names the GCNO files '-.gcno'.
> 
> With your patch they get put into a specified directory.  But,
> unless I am prepared to create over 16,000 directories each to
> hold just one file (I'm not), it is not sufficient.
> 
> What I want to do -- unless it is going to create problems -- is
> to place the notes files alongside the object files.  The files
> foo.o and foo.gcno would be in the same directory.
> 

I would recommend that. You can achieve that with -fprofile-note-dir=.

Martin

RE: gcc: -ftest-coverage and -auxbase

[David.Taylor]

> Am 20.06.19 um 15:00 schrieb David.Taylor@dell.com:
> > Dell Customer Communication - Confidential
> 
> Can't expect me to read this, then? :-)

Grumble.  For every email, even internal ones, we are asked
it's 'sensitivity'.  I explicitly marked that one as 'external public'.
It should not have said 'customer communication - confidential'.

David

p.s.  I hate Outlook.

RE: gcc: -ftest-coverage and -auxbase

[David.Taylor]

> From: Martin Liška <mliska@suse.cz>
> Sent: Thursday, June 20, 2019 9:07 AM
> 
> On 6/20/19 3:00 PM, David.Taylor@dell.com wrote:
> >
> >> From: Martin Liška <mliska@suse.cz>
> >> Sent: Thursday, June 20, 2019 5:12 AM
> >>
> >> On 6/19/19 7:11 PM, David.Taylor@dell.com wrote:
> >>> Thanks for the patch.  Standalone it is not sufficient.  Combined
> >>> with the other two changes that have been discussed --
> >>
> >> Why is that not sufficient? If you build from top-level and you have
> >> .o files that overwrite each other, then you can set
> >> -fprofile-note-dir=/tmp/my- unique-folder
> >>
> >> And you'll not overwrite .gcno files.
> >>
> >> Martin
> >
> > Right now GCC names the GCNO files '-.gcno'.
> >
> > With your patch they get put into a specified directory.  But, unless
> > I am prepared to create over 16,000 directories each to hold just one
> > file (I'm not), it is not sufficient.
> >
> > What I want to do -- unless it is going to create problems -- is to
> > place the notes files alongside the object files.  The files foo.o and
> > foo.gcno would be in the same directory.

> I would recommend that. You can achieve that with -fprofile-note-dir=.

But unless some other change is also made, the '-o -' part of our
compilation line results in all the notes files having names of
'-.gcno'.  While I have considered replacing the '-o -' with '-pipe'
when doing instrumentation, I am loathe to make the dot c to 
dot o rule any more complicated -- it is already 30+ lines long.

Your patch makes things much better.  And for many it would be sufficient.  For us, sadly, it is not enough.

Re: gcc: -ftest-coverage and -auxbase

[Martin Liška]

[-- Attachment #1: Type: text/plain, Size: 1897 bytes --]

On 6/20/19 3:29 PM, David.Taylor@dell.com wrote:
>> From: Martin Liška <mliska@suse.cz>
>> Sent: Thursday, June 20, 2019 9:07 AM
>>
>> On 6/20/19 3:00 PM, David.Taylor@dell.com wrote:
>>>
>>>> From: Martin Liška <mliska@suse.cz>
>>>> Sent: Thursday, June 20, 2019 5:12 AM
>>>>
>>>> On 6/19/19 7:11 PM, David.Taylor@dell.com wrote:
>>>>> Thanks for the patch.  Standalone it is not sufficient.  Combined
>>>>> with the other two changes that have been discussed --
>>>>
>>>> Why is that not sufficient? If you build from top-level and you have
>>>> .o files that overwrite each other, then you can set
>>>> -fprofile-note-dir=/tmp/my- unique-folder
>>>>
>>>> And you'll not overwrite .gcno files.
>>>>
>>>> Martin
>>>
>>> Right now GCC names the GCNO files '-.gcno'.
>>>
>>> With your patch they get put into a specified directory.  But, unless
>>> I am prepared to create over 16,000 directories each to hold just one
>>> file (I'm not), it is not sufficient.
>>>
>>> What I want to do -- unless it is going to create problems -- is to
>>> place the notes files alongside the object files.  The files foo.o and
>>> foo.gcno would be in the same directory.
> 
>> I would recommend that. You can achieve that with -fprofile-note-dir=.
> 
> But unless some other change is also made, the '-o -' part of our
> compilation line results in all the notes files having names of
> '-.gcno'.  While I have considered replacing the '-o -' with '-pipe'
> when doing instrumentation, I am loathe to make the dot c to 
> dot o rule any more complicated -- it is already 30+ lines long.
> 
> Your patch makes things much better.  And for many it would be sufficient.  For us, sadly, it is not enough.
> 

I see. What about the following patch:

$ ./gcc/xgcc -Bgcc /tmp/main.c --coverage -fprofile-note=/tmp/main.gcno
$ ls -l /tmp/main.gcno
-rw-r--r-- 1 marxin users 428 Jun 20 15:48 /tmp/main.gcno

Martin

[-- Attachment #2: 0001-Add-fprofile-note-option.patch --]
[-- Type: text/x-patch, Size: 1624 bytes --]

From 30eb7f04c2ee84b5199ea908c8b72cec2163825f Mon Sep 17 00:00:00 2001
From: Martin Liska <mliska@suse.cz>
Date: Thu, 20 Jun 2019 15:47:18 +0200
Subject: [PATCH] Add -fprofile-note option.

---
 gcc/common.opt |  4 ++++
 gcc/coverage.c | 11 ++++++++---
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/gcc/common.opt b/gcc/common.opt
index a1544d06824..c1b90562b9b 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2096,6 +2096,10 @@ Common Joined RejectNegative Var(profile_data_prefix)
 Set the top-level directory for storing the profile data.
 The default is 'pwd'.
 
+fprofile-note=
+Common Joined RejectNegative Var(profile_note_location)
+Select the name for storing the profile note file.
+
 fprofile-correction
 Common Report Var(flag_profile_correction)
 Enable correction of flow inconsistent profile data input.
diff --git a/gcc/coverage.c b/gcc/coverage.c
index 1ffefd5f482..960ff7ee86a 100644
--- a/gcc/coverage.c
+++ b/gcc/coverage.c
@@ -1255,9 +1255,14 @@ coverage_init (const char *filename)
   /* Name of bbg file.  */
   if (flag_test_coverage && !flag_compare_debug)
     {
-      bbg_file_name = XNEWVEC (char, len + strlen (GCOV_NOTE_SUFFIX) + 1);
-      memcpy (bbg_file_name, filename, len);
-      strcpy (bbg_file_name + len, GCOV_NOTE_SUFFIX);
+      if (profile_note_location)
+	bbg_file_name = xstrdup (profile_note_location);
+      else
+	{
+	  bbg_file_name = XNEWVEC (char, len + strlen (GCOV_NOTE_SUFFIX) + 1);
+	  memcpy (bbg_file_name, filename, len);
+	  strcpy (bbg_file_name + len, GCOV_NOTE_SUFFIX);
+	}
 
       if (!gcov_open (bbg_file_name, -1))
 	{
-- 
2.21.0

RE: gcc: -ftest-coverage and -auxbase

[David.Taylor]

Dell Customer Communication - Confidential

> From: Martin Liška <mliska@suse.cz>
> Sent: Thursday, June 20, 2019 9:49 AM

> I see. What about the following patch:
> 
> $ ./gcc/xgcc -Bgcc /tmp/main.c --coverage 
> -fprofile-note=/tmp/main.gcno $ ls -l /tmp/main.gcno
> -rw-r--r-- 1 marxin users 428 Jun 20 15:48 /tmp/main.gcno

I haven't tried it.  But, looking it over it looks like it will do everything that I need.  I'll try it and let you know.  Thanks.

RE: gcc: -ftest-coverage and -auxbase

[David.Taylor]

> From: Martin Liška <mliska@suse.cz>
> Sent: Thursday, June 20, 2019 9:49 AM

> I see. What about the following patch:
>
> $ ./gcc/xgcc -Bgcc /tmp/main.c --coverage -fprofile-note=/tmp/main.gcno $
> ls -l /tmp/main.gcno
> -rw-r--r-- 1 marxin users 428 Jun 20 15:48 /tmp/main.gcno

Thanks.  That did the trick.

Next, I will be looking at modifying GCC to do one
or both of two things --

. put the coverage variables into a section named on
  the command line instead of .data.  The .data section
  would remain the default.

. when requested on the command line, initialize the
  instrumentation variables at run time instead of at
  compile time.  Compile time would remain the default.

I haven't looked into the implementation of either, but the
former feels easy.  The latter is much more useful for us, but
I expect it is also significantly harder.

My thinking is that I will implement the former and will look into
how hard the latter is.  Depending on the outcome / other demands
on my time, I might implement it as well.

Background (or why do I want this):

Our use is embedded.  We disallow .data.  Specialized data,
for example, read-only data or data that goes into a different
named section, is allowed.  (Part of why we disallow .data is that
we support warm boot, not just cold boot.)

If neither was implemented, then for files currently without .data,
we could alter the linker script.  This would mean that files with
.data would be uninstrumentable.  Not ideal.

If the former was implemented, then any file which is not time
critical nor containing code called by the instrumentation code
would be instrumentable.

If the latter was implemented, then that would facilitate clearing
the data on demand.  Since one of the goals is not just to collect
coverage data but to also learn what coverage is provided by each
test or collection of tests, that is greatly facilitated by being able to
clear the accumulated results on demand.  A cold boot would take
20-30 minutes and you might need to 'set up' the tests...

Re: gcc: -ftest-coverage and -auxbase

[Richard Biener]

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).

> 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

gcc: -ftest-coverage and -auxbase

[David.Taylor]

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.

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