Mail Archives: djgpp/2000/04/02/08:50:19
On Fri, 24 Mar 2000, Francisco Pastor wrote:
> The OS is MSDOS 6.22
>
> CONFIG.SYS file:
[snip]
> DEVICEHIGH /L:1,4560 =C:\WINDOWS\IFSHLP.SYS
>
> AUTOEXEC.BAT file:
>
> @ECHO OFF
> PATH C:\DOS;C:\WINDOWS;C:\UTIL;C:\RED
I don't get it: you are telling that the OS is MS-DOS, but the above
lines from CONFIG.SYS and AUTOEXEC.BAT clearly show that you are
working from Windows. What am I missing?
> > Do the overruns happen even if you don't set any breakpoints in the
> > debugged program? That is, do you see the overruns when you do
> > something like this:
> >
> > gdb yourprog
> > r <put here any arguments needed by the program>
>
> Ok, overrun appears without breakpoints
Does your program use some DPMI functions directly, or issue lots of
DOS/BIOS calls? If so, please tell what those functions are.
GDB hooks the DPMI API interrupt 31h and monitors it to find some
specific functions (like allocate LDT, set selector limit,
allocate/free DOS memory, etc.) because they require special actions
by the debug support, to maintain an illusion of two separate
processes.
Other than that, I cannot see how can a debugger slow down your
program even when you don't set any breakpoints.
> > GDB (well, actually the DJGPP debug support functions linked into
> > GDB) hooks the timer and keyboard hardware interrupts, so it could
> > theoretically slow down programs which use those, but it does nothing
> > with the serial interrupt. So, as long as you don't set any
> > breakpoints, there should be no slow-down due to GDB, I think.
>
> I possible cause of overruns is if timer or keyboard interrupt spends more
> time than the interval between two interrupts in serial communication (but I
> think that 4 miliseconds for 2400 bps is a long time) .
The handler that GDB installs for the keyboard interrupt simply ljmp's
to the original handler. So this cannot by itself slow down the
program.
> My program also hook
> the timer interrupt and I suppose that this replace the gdb handler.
No, GDB restores its own timer handler each time the execution thread
returns to the debugger, and hooks the timer again with the debuggee's
handler before running it.
So this, again, does not explain the slow down.
- Raw text -