Mail Archives: djgpp/2001/03/08/16:51:33.1
On Thu, 08 Mar 2001 17:59:12 GMT, damon AT WRONG DOT redshift DOT com (Damon
Casale) wrote:
>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...
Didn't end up trying it, but I did find the problem.
>>> 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.
I did some testing to see if the timer interrupt handler was getting
switched back to the normal one somehow. It wasn't. I realized that
I was mucking around in the wrong part of my disk i/o code when the
printf I stuck in there didn't do anything, tho. :-)
Then I tried doing a STI again in the _right_ part of the code.
Presto! Gprof gave me much more reasonable output:
Each sample counts as 0.0555556 seconds.
% cumulative self self total
time seconds seconds calls s/call s/call name
40.35 510.50 510.50 220776351 0.00 0.00 longest_match
26.47 845.44 334.94 10732 0.03 0.09 deflate_slow
12.90 1008.67 163.22 __dpmi_int
4.58 1066.67 58.00 16228 0.00 0.00 compress_block
... (etc.)
Therefore, the problem must be that doing an INT13h, AH=42h or 43h
turns off interrupts, for whatever reason. (Well, either that, or the
turning off of interrupts happens as a result of one of the other
interrupt calls I make, 'cause I certainly don't do it in my own
code!)
Odd. But at least it works now. ^_^
Damon Casale, damon AT WRONG DOT redshift DOT com (remove the obvious)
STIck that in your pipe and smoke it.
- Raw text -