public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* Problems with gcov
@ 2004-08-01 20:51 Andrew Wall
  2004-08-02  0:34 ` James E Wilson
  0 siblings, 1 reply; 3+ messages in thread
From: Andrew Wall @ 2004-08-01 20:51 UTC (permalink / raw)
  To: gcc-bugs

Hi,
I've asked on the comp.os.msdos.djgpp newsgroup about gcov and been refered
to you.
I'm using gpp/gcov from djgpp versions 3.4.1 on Windows XP.

I have written 'testctor.cpp' and 'testctor.bat' which produces the output
'testctor.cpp.gcov':
testctor.cpp: which is a small test program which has a static instance of a
class with both a constructor and a destructor.
===============
// Test constructors/destructors:
#include <iostream>
using namespace std;
class Test {
public:
	Test(void){
	cout<< "In Test ctor" << endl;
	}
	~Test(void){
	cout<< "In Test dtor" << endl;
	}
}T1;

void uncalled(void){
	cout<< "In uncalled" << endl;
}
int main(void){
// Test T2;
cout<< "In main" << endl;
return 0;
}
===============

Testctor.bat:
===============
gpp -o testctor.exe testctor.cpp -fprofile-arcs -ftest-coverage -lgcov
testctor.exe
gcov testctor.cpp
===============
which shows how I compiled the above source file, ran the resulting program
and ran gcov to produce a .gcov output.

testctor.cpp.gcov
===============
        -:    0:Source:testctor.cpp
        -:    0:Graph:testctor.gcno
        -:    0:Data:testctor.gcda
        -:    0:Runs:1
        -:    0:Programs:1
        -:    1:// Test constructors/destructors:
        -:    2:#include <iostream>
        -:    3:using namespace std;
        -:    4:class Test {
        -:    5:public:
function _ZN4TestC1Ev called 1 returned 100% blocks executed 100%
        1:    6:	Test(void){
        1:    7:	cout<< "In Test ctor" << endl;
        -:    8:	}
function _ZN4TestD1Ev called 0 returned 0% blocks executed 0%
    #####:    9:	~Test(void){
    #####:   10:	cout<< "In Test dtor" << endl;
        -:   11:	}
        1:   12:}T1;
        -:   13:
function _Z8uncalledv called 0 returned 0% blocks executed 0%
    #####:   14:void uncalled(void){
    #####:   15:	cout<< "In uncalled" << endl;
        -:   16:}
function main called 1 returned 100% blocks executed 100%
        1:   17:int main(void){
        -:   18:// Test T2;
        1:   19:cout<< "In main" << endl;
        1:   20:return 0;
function _Z41__static_initialization_and_destruction_0ii called 1 returned
100% blocks executed 76%
        2:   21:}
function _GLOBAL__I_T1 called 1 returned 100% blocks executed 100%
        2:   22:/*EOF*/
function _GLOBAL__D_T1 called 0 returned 0% blocks executed 0%
    #####:   23:/*EOF*/
===============
The problem I can see is that while gcov correcty reports that the function
'void uncalled(void)' is in fact not called, it incorrectly reports that the
destructor ~Test(void) is not called.
The run of the program demonstrates that the destructor _is_ called.

Can you give me any help with this?

Andrew Wall

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.729 / Virus Database: 484 - Release Date: 27/07/2004
 


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

* Re: Problems with gcov
  2004-08-01 20:51 Problems with gcov Andrew Wall
@ 2004-08-02  0:34 ` James E Wilson
  2004-08-02 20:51   ` Andrew Wall
  0 siblings, 1 reply; 3+ messages in thread
From: James E Wilson @ 2004-08-02  0:34 UTC (permalink / raw)
  To: Andrew Wall; +Cc: gcc-bugs

Andrew Wall wrote:
> The problem I can see is that while gcov correcty reports that the function
> 'void uncalled(void)' is in fact not called, it incorrectly reports that the
> destructor ~Test(void) is not called.
> The run of the program demonstrates that the destructor _is_ called.

Gcov needs to initialize some data when the program starts, and write 
some data to a file when the program exits.  This works fine for C 
files, but for C++ programs which have their own static 
constructors/destructors that also run at program start and exit, then 
we have an ordering problem.  If the gcov exit function runs before your 
static destructor, then indeed the output file correctly claims that 
your static destructor was never run (yet).

It isn't hard to see this by running the program under gdb, putting a 
breakpoint in fwrite, and then noting that the gcov exit function runs 
before your static destructor.

We use a static constructor to initialize gcov, and a call to atexit to 
register the exit function.  I don't know offhand if there is anything 
we can do to fix this.  Though it is curious that this works in gcc-3.3 
but not in gcc-3.4.  I don't see any obvious difference in the assembly 
language.  Maybe there was a change to the order in which we run static 
constructors?

We don't track bug reports mailed to this list.  If you want a solution, 
then you should consider filing a bug report into our bugzilla bug 
database.  See
     http://gcc.gnu.org/bugzilla
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com


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

* RE: Problems with gcov
  2004-08-02  0:34 ` James E Wilson
@ 2004-08-02 20:51   ` Andrew Wall
  0 siblings, 0 replies; 3+ messages in thread
From: Andrew Wall @ 2004-08-02 20:51 UTC (permalink / raw)
  To: 'James E Wilson'; +Cc: gcc-bugs

James,
Thanks for your prompt reply.

I'm very surprised that the compiler writers themselves cannot arrange for
their own specific compiler switches to arrange for an object to be
constructed first and thus destructed last.

I'll see if I can file a report on bugzilla, but in the mean time I might
investigate regressing to gcc-3.3, or see if I can write programs that hide
the static destructors from gcov.

Andrew -Wall


> -----Original Message-----
> From: James E Wilson [mailto:wilson@specifixinc.com] 
> Sent: 02 August 2004 01:35
> To: Andrew Wall
> Cc: gcc-bugs@gcc.gnu.org
> Subject: Re: Problems with gcov
> 
> 
> Andrew Wall wrote:
> > The problem I can see is that while gcov correcty reports that the
function
> > 'void uncalled(void)' is in fact not called, it incorrectly reports that
the
> > destructor ~Test(void) is not called.
> > The run of the program demonstrates that the destructor _is_ called.
> 
> Gcov needs to initialize some data when the program starts, and write 
> some data to a file when the program exits.  This works fine for C 
> files, but for C++ programs which have their own static 
> constructors/destructors that also run at program start and exit, then 
> we have an ordering problem.  If the gcov exit function runs before your 
> static destructor, then indeed the output file correctly claims that 
> your static destructor was never run (yet).
> 
> It isn't hard to see this by running the program under gdb, putting a 
> breakpoint in fwrite, and then noting that the gcov exit function runs 
> before your static destructor.
> 
> We use a static constructor to initialize gcov, and a call to atexit to 
> register the exit function.  I don't know offhand if there is anything 
> we can do to fix this.  Though it is curious that this works in gcc-3.3 
> but not in gcc-3.4.  I don't see any obvious difference in the assembly 
> language.  Maybe there was a change to the order in which we run static 
> constructors?
> 
> We don't track bug reports mailed to this list.  If you want a solution, 
> then you should consider filing a bug report into our bugzilla bug 
> database.  See
>      http://gcc.gnu.org/bugzilla
> -- 
> Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.729 / Virus Database: 484 - Release Date: 27/07/2004
 


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

end of thread, other threads:[~2004-08-02 20:51 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-08-01 20:51 Problems with gcov Andrew Wall
2004-08-02  0:34 ` James E Wilson
2004-08-02 20:51   ` Andrew Wall

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).