Mail Archives: djgpp/2001/03/08/13:06:41
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.
- Raw text -