Michelle Caisse wrote:
Thanks, I'll take a look at these issues.
I have committed your patch with some rework that mainly addresses the
concerns also found by Alvaro with regard to cleaning and dependency
handling. I have renamed the out target to coverage-html, to be more in
line with our
Peter Eisentraut [EMAIL PROTECTED] writes:
I have uploaded an example run here:
http://developer.postgresql.org/~petere/coverage/
Current test coverage is about 66% overall.
With some pretty glaring gaps: 0% coverage of geqo, 0% coverage of logtape
which implies no tuplesorts are spilling to
Gregory Stark wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
I have uploaded an example run here:
http://developer.postgresql.org/~petere/coverage/
Current test coverage is about 66% overall.
With some pretty glaring gaps: 0% coverage of geqo, 0% coverage of logtape
which implies
Michelle Caisse wrote:
I've attached a patch that allows the generation of code coverage
statistics. To test it, apply the patch, then:
autoconf
./configure --enable-coverage
make
make check (or execute any other application against the database to see
the coverage of that app)
make
Thanks, I'll take a look at these issues.
-- Michelle
Alvaro Herrera wrote:
Michelle Caisse wrote:
I've attached a patch that allows the generation of code coverage
statistics. To test it, apply the patch, then:
autoconf
./configure --enable-coverage
make
make check (or execute any
Peter Eisentraut wrote:
Michelle Caisse wrote:
gcov gets confused when source files are generated. I eliminated
src/backend/bootstrap and ../parser from coverage analysis to avoid
errors of this type.
The problem with those files is that the source file contains lines like this:
#line 1042
Michelle Caisse wrote:
gcov gets confused when source files are generated. I eliminated
src/backend/bootstrap and ../parser from coverage analysis to avoid
errors of this type.
The problem with those files is that the source file contains lines like this:
#line 1042 y.tab.c
but that source
Michelle Caisse wrote:
Also, two tests fail with the following diff when the build is
configured with --enable-coverage.
RETURNS trigger
AS
'/home/michelle/trunkClean/pgsql/src/test/regress/../../../contrib/spi/refi
nt.so' LANGUAGE C;
+ ERROR: could not load library
Peter Eisentraut [EMAIL PROTECTED] writes:
The reason for that problem is that the shared object needs to be linked
with -fprofile-arcs -ftest-coverage. (One of these causes -lgcov to be
linked, which includes the missing symbol.) This is not done because the
shared object link rules
Gregory Stark wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
The reason for that problem is that the shared object needs to be linked
with -fprofile-arcs -ftest-coverage. (One of these causes -lgcov to be
linked, which includes the missing symbol.) This is not done because the
shared
The problem with those files is that the source file contains lines
like this:
#line 1042 y.tab.c
but that source file does not exist, as it is renamed to gram.c.
We could fix that in one of two ways:
1) Use bison's -o option to put the output file in the right place
directly,
if we are
Korry Douglas wrote:
1) Use bison's -o option to put the output file in the right place
directly,
if we are dealing with bison (and don't bother to support code coverage
analysis with other yaccs), or
2) Run a pattern replacement across the grammar output files as their are
renamed.
Why not
Peter Eisentraut [EMAIL PROTECTED] writes:
Korry Douglas wrote:
Why not use the %output directive in the grammar file instead; that way
you don't need to add any special flags to the Makefile.
I think only bison supports that directive.
We're pretty much assuming bison anyway, no? It's
Tom Lane wrote:
We're pretty much assuming bison anyway, no? It's been years since
I heard of anyone successfully building the backend grammar with plain
yacc.
In my recollection, you were the last holdout on that with the
occasional HP-UX yacc test. But I seem to recall that that
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
We're pretty much assuming bison anyway, no? It's been years since
I heard of anyone successfully building the backend grammar with plain
yacc.
In my recollection, you were the last holdout on that with the
occasional HP-UX yacc
I've attached a patch that allows the generation of code coverage
statistics. To test it, apply the patch, then:
autoconf
./configure --enable-coverage
make
make check (or execute any other application against the database to see
the coverage of that app)
make coverage
make coverage_out
You
16 matches
Mail list logo
