All of lore.kernel.org
 help / color / mirror / Atom feed
* Ceph code coverage integration proposal
@ 2011-06-02 18:05 Tommi Virtanen
  2011-06-02 21:09 ` Josh Durgin
  0 siblings, 1 reply; 4+ messages in thread
From: Tommi Virtanen @ 2011-06-02 18:05 UTC (permalink / raw)
  To: ceph-devel

[This is mostly for Josh, but I'm sending to list for general
awareness and archival.]

Things learned:

- when you compile something to record code coverage data,
  it remembers the absolute path of the source files, even if your
  build system only used relative paths

- when you compile something to record code coverage data,
  you get a *.gcno file with extra information

- execution-time data recording needs no auxiliary files, it's a
  write-only operation

- it tries to write the *.gcda files to the full absolute path,
  creating any leading directories as needed

- in our case, the paths are /srv/autobuild-ceph/... for normal
  gitbuilder, something else for the deb builder, just about anything
  for developers' own builds; the dir will not exist just about
  anywhere, and would be ugly & unreliable to try to use; we need to
  use the gcov feature to relocate the files

- if it can't create leading dirs / write to files, stderr gets
  "profiling:/full/path/to/file.gcda:Cannot open" but execution
  continues

- we can control where the *.gcda files are written, with environment
  variables; however, GCOV_PREFIX_STRIP is annoying to use, needs
  information from build time

- the gcov command itself reads the *.gcno and *.gcda files and the
  source; there's no need to e.g. preserve the .o files; for
  gitbuilders etc that only build committed trees, we can re-fetch
  the source from git at any time if needed


Proposal:

- add autoconf flag --enable-coverage, or some such (afaik Josh has
  this already), that compiles with coverage recording

- get "make check" to record coverage for unit tests and clitests,
  do something to analyze those nicely (separate make target to avoid
  automake brain damage?)

- get "make install" to install the *.gcno to usr/local/ceph/coverage
  or such (no need to even create the directory if not --enable-coverage)

- add src/ceph-coverage.in:

--8<--
#!/bin/sh
set -e

export GCOV_PREFIX_STRIP=@@GCOV_PREFIX_STRIP@@

usage () {
      printf '%s: usage: %s OUTPUTDIR COMMAND [ARGS..]\n' "$(basename "$0")" "$(basename "$0")" 1>&2
      exit 1
}

export GCOV_PREFIX="$1"
[ -n "$GCOV_PREFIX" ] || usage
shift

case "$GCOV_PREFIX" in
    /*)
	# absolute path -> ok
	;;
    *)
	# make it absolute
	GCOV_PREFIX="$PWD/$GCOV_PREFIX"
	;;
esac

exec "$@"
--8<--

  and get Makefile.am to create ceph-coverage out of that; substitute
  @@GCOV_PREFIX_STRIP@@ at build time with value of "$(pwd|tr -dc /|wc -c)"
  and install the script to usr/local/bin/ceph-coverage

- make integration tests run everything interesting as
  "/blah/blah/usr/local/bin/ceph-coverage /blah/coverage /blah/blah/usr/local/bin/cosd ..."
  do this even when not profiling, just to have the same code path always

- get another gitbuilder (just x86_64 i guess) to build with
  --enable-profile; individual test runs can use ceph binary tarball
  url to get the profiling builds

... and this is where it gets sketchy ...

- FAILED IDEA: make integration tests post-process the gcov data to
  *.{c,cc,...}.gcov etc

  PROBLEM: this means test box would need the source on it?? this has
  previously not been true

  BETTER: postprocess them elsewhere, like the place where we want
  to draw pretty charts and aggregate data across runs? unclear.. but
  if we archive the *.gcno, *.gcda, and can re-checkout the source, we
  can always come back to this later

- UNCLEAR: do we want to archive the *.gcno, *.gcda files, or just the
  *.{c,cc,...}.gcov?

- SUGGESTION: archive *.gcno (inside the ceph binary tarball), *.gcda,
  and git sha1 for now (the same way as e.g. log files from a test are
  archived); don't automate post-processing right now; can rsync an
  archive dir from the archive server, checkout right source tree, run
  manually, and see things work right; come back to this when the
  above works



Here's a picture for you, too:


source ---build---> binary tarball  ---run---> archive
-sha1               -binaries                  -logs etc
                    -ceph-coverage             -*.gcda
                    -*.gcno
 |                    |                          |
 |                    |                          |
  \                   |                         /
    \                 |                       /
      \               |                     /
        \             |                   /
          \           |                 /
             gcov run needs all these
                      |
                      |
               *.{c,cc,...}.gcov
                      |
                      |
                  lcov etc?


Phew.

-- 
:(){ :|:&};:

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Ceph code coverage integration proposal
  2011-06-02 18:05 Ceph code coverage integration proposal Tommi Virtanen
@ 2011-06-02 21:09 ` Josh Durgin
  2011-06-02 21:18   ` Tommi Virtanen
  0 siblings, 1 reply; 4+ messages in thread
From: Josh Durgin @ 2011-06-02 21:09 UTC (permalink / raw)
  To: Tommi Virtanen; +Cc: ceph-devel

On 06/02/2011 11:05 AM, Tommi Virtanen wrote:
<snip>
> Proposal:
>
> - add autoconf flag --enable-coverage, or some such (afaik Josh has
>    this already), that compiles with coverage recording

This is in the wip_gcov branch as --with-gcov.

> - get "make check" to record coverage for unit tests and clitests,
>    do something to analyze those nicely (separate make target to avoid
>    automake brain damage?)
>
> - get "make install" to install the *.gcno to usr/local/ceph/coverage
>    or such (no need to even create the directory if not --enable-coverage)
>
> - add src/ceph-coverage.in:
>
> --8<--
> #!/bin/sh
> set -e
>
> export GCOV_PREFIX_STRIP=@@GCOV_PREFIX_STRIP@@
>
> usage () {
>        printf '%s: usage: %s OUTPUTDIR COMMAND [ARGS..]\n' "$(basename "$0")" "$(basename "$0")" 1>&2
>        exit 1
> }
>
> export GCOV_PREFIX="$1"
> [ -n "$GCOV_PREFIX" ] || usage
> shift
>
> case "$GCOV_PREFIX" in
>      /*)
> 	# absolute path ->  ok
> 	;;
>      *)
> 	# make it absolute
> 	GCOV_PREFIX="$PWD/$GCOV_PREFIX"
> 	;;
> esac
>
> exec "$@"
> --8<--
>
>    and get Makefile.am to create ceph-coverage out of that; substitute
>    @@GCOV_PREFIX_STRIP@@ at build time with value of "$(pwd|tr -dc /|wc -c)"
>    and install the script to usr/local/bin/ceph-coverage
>
> - make integration tests run everything interesting as
>    "/blah/blah/usr/local/bin/ceph-coverage /blah/coverage /blah/blah/usr/local/bin/cosd ..."
>    do this even when not profiling, just to have the same code path always
>
> - get another gitbuilder (just x86_64 i guess) to build with
>    --enable-profile; individual test runs can use ceph binary tarball
>    url to get the profiling builds
>
> ... and this is where it gets sketchy ...
>
> - FAILED IDEA: make integration tests post-process the gcov data to
>    *.{c,cc,...}.gcov etc
>
>    PROBLEM: this means test box would need the source on it?? this has
>    previously not been true
>
>    BETTER: postprocess them elsewhere, like the place where we want
>    to draw pretty charts and aggregate data across runs? unclear.. but
>    if we archive the *.gcno, *.gcda, and can re-checkout the source, we
>    can always come back to this later

This all sounds good.

> - UNCLEAR: do we want to archive the *.gcno, *.gcda files, or just the
>    *.{c,cc,...}.gcov?
>
> - SUGGESTION: archive *.gcno (inside the ceph binary tarball), *.gcda,
>    and git sha1 for now (the same way as e.g. log files from a test are
>    archived); don't automate post-processing right now; can rsync an
>    archive dir from the archive server, checkout right source tree, run
>    manually, and see things work right; come back to this when the
>    above works

This seems to be the way to go so we can change our post-processing later.

Josh

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Ceph code coverage integration proposal
  2011-06-02 21:09 ` Josh Durgin
@ 2011-06-02 21:18   ` Tommi Virtanen
  2011-06-02 21:32     ` Josh Durgin
  0 siblings, 1 reply; 4+ messages in thread
From: Tommi Virtanen @ 2011-06-02 21:18 UTC (permalink / raw)
  To: Josh Durgin; +Cc: ceph-devel

On Thu, Jun 02, 2011 at 02:09:26PM -0700, Josh Durgin wrote:
> On 06/02/2011 11:05 AM, Tommi Virtanen wrote:
> <snip>
> >Proposal:
> >
> >- add autoconf flag --enable-coverage, or some such (afaik Josh has
> >   this already), that compiles with coverage recording
> 
> This is in the wip_gcov branch as --with-gcov.

Sweet.

BTW, I know this has been going on for a while, but autoconf wasn't
meant to be used like that.. --with-foo is supposed to be about
external libraries and such, --enable-foo is supposed to be about
features. So --with-debug should have been --enable-debug. I didn't
change that the last time I was working on autoconf, because I wanted
to limit the size of the crater I was creating, but for new stuff we
probably should do it the "right way".

-- 
:(){ :|:&};:

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Ceph code coverage integration proposal
  2011-06-02 21:18   ` Tommi Virtanen
@ 2011-06-02 21:32     ` Josh Durgin
  0 siblings, 0 replies; 4+ messages in thread
From: Josh Durgin @ 2011-06-02 21:32 UTC (permalink / raw)
  To: Tommi Virtanen; +Cc: ceph-devel

On 06/02/2011 02:18 PM, Tommi Virtanen wrote:
> On Thu, Jun 02, 2011 at 02:09:26PM -0700, Josh Durgin wrote:
>> On 06/02/2011 11:05 AM, Tommi Virtanen wrote:
>> <snip>
>>> Proposal:
>>>
>>> - add autoconf flag --enable-coverage, or some such (afaik Josh has
>>>    this already), that compiles with coverage recording
>>
>> This is in the wip_gcov branch as --with-gcov.
>
> Sweet.
>
> BTW, I know this has been going on for a while, but autoconf wasn't
> meant to be used like that.. --with-foo is supposed to be about
> external libraries and such, --enable-foo is supposed to be about
> features. So --with-debug should have been --enable-debug. I didn't
> change that the last time I was working on autoconf, because I wanted
> to limit the size of the crater I was creating, but for new stuff we
> probably should do it the "right way".

Good to know - I'll rename it --enable-coverage.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2011-06-02 21:32 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-06-02 18:05 Ceph code coverage integration proposal Tommi Virtanen
2011-06-02 21:09 ` Josh Durgin
2011-06-02 21:18   ` Tommi Virtanen
2011-06-02 21:32     ` Josh Durgin

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.