gcc: -ftest-coverage and -auxbase

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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
Reply | Threaded
Open this post in threaded view
|

Re: gcc: -ftest-coverage and -auxbase

Richard Biener-2
On Wed, Jun 12, 2019 at 10:17 PM <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: gcc: -ftest-coverage and -auxbase

David Taylor-5
In reply to this post by 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: gcc: -ftest-coverage and -auxbase

Richard Biener-2
On Mon, Jun 17, 2019 at 2:46 PM David Taylor <[hidden email]> 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

RE: gcc: -ftest-coverage and -auxbase

David.Taylor
> From: Richard Biener <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: gcc: -ftest-coverage and -auxbase

Richard Biener-2
On Mon, Jun 17, 2019 at 5:02 PM <[hidden email]> wrote:

>
> > From: Richard Biener <[hidden email]>
> > 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 <[hidden email]> 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 <[hidden email]> 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.
>
Reply | Threaded
Open this post in threaded view
|

Re: gcc: -ftest-coverage and -auxbase

Martin Liška-2
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
Reply | Threaded
Open this post in threaded view
|

RE: gcc: -ftest-coverage and -auxbase

David.Taylor
Dell Customer Communication - Confidential

> From: Martin Liška <[hidden email]>
> 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...
Reply | Threaded
Open this post in threaded view
|

Re: gcc: -ftest-coverage and -auxbase

Martin Liška-2
On 6/18/19 3:31 PM, [hidden email] wrote:

> Dell Customer Communication - Confidential
>
>> From: Martin Liška <[hidden email]>
>> 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...
>

Reply | Threaded
Open this post in threaded view
|

RE: gcc: -ftest-coverage and -auxbase

David.Taylor
> From: Martin Liška <[hidden email]>
> 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.


Reply | Threaded
Open this post in threaded view
|

Re: gcc: -ftest-coverage and -auxbase

Martin Liška-2
On 6/18/19 11:51 PM, [hidden email] wrote:

>> From: Martin Liška <[hidden email]>
>> 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.
>
>


fprofile-note-dir.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: gcc: -ftest-coverage and -auxbase

David.Taylor
Dell Customer Communication - Confidential

> From: Martin Liška <[hidden email]>
> Sent: Wednesday, June 19, 2019 3:19 AM
>
> On 6/18/19 11:51 PM, [hidden email] wrote:
> >> From: Martin Liška <[hidden email]>
> >> 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.
> >
> >
Reply | Threaded
Open this post in threaded view
|

Re: gcc: -ftest-coverage and -auxbase

Martin Liška-2
On 6/19/19 7:11 PM, [hidden email] 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
Reply | Threaded
Open this post in threaded view
|

RE: gcc: -ftest-coverage and -auxbase

David.Taylor
Dell Customer Communication - Confidential

> From: Martin Liška <[hidden email]>
> Sent: Thursday, June 20, 2019 5:12 AM
> To: taylor, david; [hidden email]
> Cc: [hidden email]
> Subject: Re: gcc: -ftest-coverage and -auxbase
>
> On 6/19/19 7:11 PM, [hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: gcc: -ftest-coverage and -auxbase

Thomas Koenig-6
Am 20.06.19 um 15:00 schrieb [hidden email]:
> Dell Customer Communication - Confidential

Can't expect me to read this, then? :-)
Reply | Threaded
Open this post in threaded view
|

Re: gcc: -ftest-coverage and -auxbase

Martin Liška-2
In reply to this post by David.Taylor
On 6/20/19 3:00 PM, [hidden email] wrote:

> Dell Customer Communication - Confidential
>
>> From: Martin Liška <[hidden email]>
>> Sent: Thursday, June 20, 2019 5:12 AM
>> To: taylor, david; [hidden email]
>> Cc: [hidden email]
>> Subject: Re: gcc: -ftest-coverage and -auxbase
>>
>> On 6/19/19 7:11 PM, [hidden email] 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
Reply | Threaded
Open this post in threaded view
|

RE: gcc: -ftest-coverage and -auxbase

David.Taylor
In reply to this post by Thomas Koenig-6
> Am 20.06.19 um 15:00 schrieb [hidden email]:
> > 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.
Reply | Threaded
Open this post in threaded view
|

RE: gcc: -ftest-coverage and -auxbase

David.Taylor
In reply to this post by Martin Liška-2
> From: Martin Liška <[hidden email]>
> Sent: Thursday, June 20, 2019 9:07 AM
>
> On 6/20/19 3:00 PM, [hidden email] wrote:
> >
> >> From: Martin Liška <[hidden email]>
> >> Sent: Thursday, June 20, 2019 5:12 AM
> >>
> >> On 6/19/19 7:11 PM, [hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: gcc: -ftest-coverage and -auxbase

Martin Liška-2
On 6/20/19 3:29 PM, [hidden email] wrote:

>> From: Martin Liška <[hidden email]>
>> Sent: Thursday, June 20, 2019 9:07 AM
>>
>> On 6/20/19 3:00 PM, [hidden email] wrote:
>>>
>>>> From: Martin Liška <[hidden email]>
>>>> Sent: Thursday, June 20, 2019 5:12 AM
>>>>
>>>> On 6/19/19 7:11 PM, [hidden email] 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

0001-Add-fprofile-note-option.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: gcc: -ftest-coverage and -auxbase

David.Taylor
Dell Customer Communication - Confidential

> From: Martin Liška <[hidden email]>
> 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.
12