From: damon AT WRONG DOT redshift DOT com (Damon Casale)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: GPROF reports zero time spent?
Date: Thu, 08 Mar 2001 17:59:12 GMT
Organization: Posted via Supernews, http://www.supernews.com
Message-ID: <3aa7c5f5.208835@news.redshift.com>
References: <3aa69f21 DOT 386105 AT news DOT redshift DOT com> <9867vf$9ts$1 AT nets3 DOT rz DOT RWTH-Aachen DOT DE> <3aa6b9b7 DOT 800087 AT news DOT redshift DOT com> <7263-Thu08Mar2001090237+0200-eliz AT is DOT elta DOT co DOT il>
X-Newsreader: Forte Free Agent 1.21/32.243
X-Complaints-To: newsabuse AT supernews DOT com
Lines: 56
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

On Thu, 08 Mar 2001 09:02:38 +0200, "Eli Zaretskii"
<eliz AT is DOT elta DOT co DOT il> wrote:

>> From: damon AT WRONG DOT redshift DOT com (Damon Casale)
>> Newsgroups: comp.os.msdos.djgpp
>> Date: Wed, 07 Mar 2001 22:54:18 GMT
>> >
>> >> Each sample counts as 0.0555556 seconds.
>> >>   %   cumulative   self              self     total           
>> >>  time   seconds   seconds    calls  Ts/call  Ts/call  name    
>> >> 100.00    424.17   424.17                             __dpmi_int
>> >
>> >See the FAQ. In a nutshell: either you've hit a gprof bug, or your
>> >program is completely bottlenecked by I/O operations.
>> 
>> Hmm.  Apparently, I already have DJGPP v2.03.
>
>Are you sure?  The above output surely look amazingly similar to the
>problem with v2.02 library described in the FAQ.  How did you check
>that you have v2.03?

I checked my install directory.  I have the BinUtils 2.9.5.1 (or
however you arrange the dots) zip file there.  I checked the date/time
stamp of gprof in the zip file and compared it with the gprof on my
test machine.  Same date/time stamp, same file size.

>One way to be sure is to compile and link a simple program with -pg,
>then profile it.  If that shows a non-trivial profile, I'd suggest
>recompile and relink your real program and try again.

Okay, I'll try that...

>> I'm beginning to suspect that interrupts might have gotten turned off
>> somehow, or something like that.
>
>The only thing that can disable profiling is to turn off the timer
>tick, or catch it in your code and never chain to the previous
>handlers.

*shrug*  My code doesn't do that.  I do know that I _used_ to use
uclock() in my code, and that the result that it returned was "slow."
setitimer() (which is what gprof uses to set the timer) calls uclock()
internally.  That may be what's goofing it up, although why uclock()
is slow in the first place, I still don't know.

I have a function to reset the system clock by grabbing the current
time from the CMOS and calling settime.  I call this at the end of my
program, and it fixes things up.  I've tried calling this after my
disk access interrupt calls, but it doesn't fix gprof's output.
Putting a STI assembly statement in there to turn on interrupts, if
they've somehow gotten turned off, doesn't seem to help either.

Damon Casale, damon AT WRONG DOT redshift DOT com (remove the obvious)
They say that for kids, time goes by twice as fast.  Computers must be
just the opposite.