debugging and protected mode
Author |
Message |
nb #1 / 12
|
debugging and protected mode
Why doesn't work the de{*filter*} in protected mode ? nb
|
Sun, 02 May 2004 05:58:14 GMT |
|
|
Jason Burgo #2 / 12
|
debugging and protected mode
Quote:
> Why doesn't work the de{*filter*} in protected mode ?
Because Borland couldn't be bothered to make to integrate their p/m de{*filter*} into the IDE. No real hardship though, since the standalone de{*filter*}s (TD286.EXE for r/m apps, and TDX.EXE for p/m apps) are much better than the integrated de{*filter*} anyway. So, exit BP.EXE and run TDX.EXE. I write a little TD.BAT file in the appropriate directory which contains somethng like this: tdx -do -p- MyProg That way I get the de{*filter*} displayed on my very old Phillips 12" mono monitor, leaving my main monitor free for program output. -- Jay Jason Burgon - Author of "Graphic Vision" GUI for DOS/DPMI === Free LFN capable Dos/WinDos replacement and === === New Graphic Vision version 2.12 available from: === http://www.*-*-*.com/
|
Mon, 03 May 2004 01:05:59 GMT |
|
|
Jan Philip #3 / 12
|
debugging and protected mode
On Wed, 14 Nov 2001 17:05:59 -0000, "Jason Burgon" Quote:
>Because Borland couldn't be bothered to make to integrate their p/m de{*filter*} >into the IDE. No real hardship though, since the standalone de{*filter*}s >(TD286.EXE for r/m apps, and TDX.EXE for p/m apps) are much better than the >integrated de{*filter*} anyway.
I always strongly preferred the integrated de{*filter*}. It was so much easier to get things done. If I had to debug a protected mode program, I tried to have a non-protected mode version.
|
Mon, 03 May 2004 08:15:09 GMT |
|
|
Femme Verbee #4 / 12
|
debugging and protected mode
Quote: > On Wed, 14 Nov 2001 17:05:59 -0000, "Jason Burgon"
> >Because Borland couldn't be bothered to make to integrate their p/m de{*filter*} > >into the IDE. No real hardship though, since the standalone de{*filter*}s > >(TD286.EXE for r/m apps, and TDX.EXE for p/m apps) are much better than the > >integrated de{*filter*} anyway. > I always strongly preferred the integrated de{*filter*}. It was so much > easier to get things done. If I had to debug a protected mode > program, I tried to have a non-protected mode version.
I never managed to use the external de{*filter*}s to work in the same way as the integrated one. (or never tried hard enough). Somehow it displayed the contents of the registers etc. which does not mean anything to me. Can any one write a very short instruction how to get started with it. The two important features are of cource: - stepping through the code while executing it - if you run your code and it crashes, the de{*filter*} can find the error address and the error code. Somehow the integrated de{*filter*} did never work in protected mode. In case a de{*filter*} is needed, i run my programs in real mode with special definitions that don't generate that much data. I can step through my code, but somehow the error address can't be found. This seems to be related to two things: -if the program is to big -if you use objects and pointer related functions. Is there a solution to this? Femme Verbeek
|
Mon, 03 May 2004 22:20:21 GMT |
|
|
Frank Peel #5 / 12
|
debugging and protected mode
... Quote: > I never managed to use the external de{*filter*}s to work in the same way as > the integrated one. > (or never tried hard enough). Somehow it displayed the contents of the > registers etc. which does not mean anything to me. Can any one write a > very short instruction how to get started with it.
Two possibilities occur to me. You need to have debug info in the .exe and the de{*filter*} needs to know where to find the source code. Turning on Debug Info in the compiler options you probably already know about. "Standalone debugging" has to be turned on as well. This puts the debug info in the .EXE file itself, rather than storing it only where the integrated de{*filter*} would be able to find it. In BP7, that's in Options|De{*filter*}. If the info is in the .exe file, but the de{*filter*} can't find the source code, it still can't do source level debugging (although it would show line numbers). You can set the path to the source code in Options|Path for Source. And of course, you must use the right Turbo De{*filter*} - the Real one won't understand the PM programs... but you knew that. FP
|
Mon, 03 May 2004 23:41:31 GMT |
|
|
Jan Philip #6 / 12
|
debugging and protected mode
Quote: >I never managed to use the external de{*filter*}s to work in the same way as >the integrated one.
You're right, they don't work the same way as an integrated de{*filter*} when you can alter the source code, recompile right there, re run it, etc. Quote: > Somehow it displayed the contents of the >registers etc. which does not mean anything to me.
The contents of registers does nothing for me either. I'm purely a high level programmer, so that low level stuff does me no good.
|
Mon, 03 May 2004 23:55:53 GMT |
|
|
Jyrki Lahtone #7 / 12
|
debugging and protected mode
Quote:
> I never managed to use the external de{*filter*}s to work in the same way as > the integrated one. > (or never tried hard enough). Somehow it displayed the contents of the > registers etc. which does not mean anything to me. Can any one write a > very short instruction how to get started with it.
To overcome this you must check a few boxes in the options menu "debug info" + may be also "standalone debugging", if you want to try debugging with tdx. It is possible to also add protected mode debugging to the usual "tools" menu. Somewhere in the help files they tell us, how to do this. I could try to recall, how I did it, but that won't be verey useful, for something went wrong when I did add DPMI debugging into the menu. I get to call the de{*filter*} all right, but it doesn't always work right. If there is a GPF (runtime error 216), I will most likely hang the entire system (assuming a pure DOS boot, even win95 has trouble coping with the situation). Or if not that, then rtm.exe remains resident (DOS) causing the system to gradually run out of memory. I guess I didn't select the right parameters (I simply copied the real mode de{*filter*} params - I really should get a copy of TFM, but nobody wants to sell me one) Quote: > The two important features are of cource: > - stepping through the code while executing it > - if you run your code and it crashes, the de{*filter*} can find the error > address and the error code. > Somehow the integrated de{*filter*} did never work in protected mode. In case > a de{*filter*} is needed, i run my programs in real mode with special > definitions that don't generate that much data. I can step through my > code, but somehow the error address can't be found. This seems to be > related to two things: > -if the program is to big > -if you use objects and pointer related functions. > Is there a solution to this?
When debugging a protected mode program sometimes the error address, indeed, seems to be out of reach. I believe that the reason to this is that somehow the error event propagated into the DPMI-service code (either rtm.exe or dpmi.ovl) and hence is unavailable to the error address finding routine within the IDE. Can anyone shed more light to this? Sometimes I have gotten useful information by designing my own "exitproc" (that is called in the case of an error, too). Declare a few global variables for the purposes of debugging. Set them to certain hopefully useful values at a suspicious part of your code and have the exitproc print their values out. Admittedly not great, something from the days before integrated debugging really, but it may help (especially the negative information that nothing was wrong with that part of the code - look elsewhere) Quote: I leave the field open for the local gurus to respond... -- Jyrki Lahtonen, docent Department of Mathematics, University of Turku, FIN-20014 Turku, Finland http://www.*-*-*.com/ tel: (02) 333 6014
|
Tue, 04 May 2004 14:04:34 GMT |
|
|
Femme Verbee #8 / 12
|
debugging and protected mode
Quote: > When debugging a protected mode program sometimes the error address, > indeed, seems to be out of reach. I believe that the reason to this is > that somehow the error event propagated into the DPMI-service code > (either rtm.exe or dpmi.ovl) and hence is unavailable to the error > address finding routine within the IDE. Can anyone shed more light to > this? > Sometimes I have gotten useful information by designing my own > "exitproc" (that is called in the case of an error, too). Declare > a few global variables for the purposes of debugging. Set them > to certain hopefully useful values at a suspicious part of your code > and have the exitproc print their values out. Admittedly not great, > something from the days before integrated debugging really, but > it may help (especially the negative information that nothing > was wrong with that part of the code - look elsewhere)
I made my own exitproc too. It even displays the error address and code. But this does not help. Aparently the adress and code come from the same limited or faulty source, which is why the internal de{*filter*} does not find the error address either. I also tried to switch off the debug information for unsuspected units, leaving more space for the suspected code to be debuggable. This did not work either, but perhaps I did not try hard enough!!!!!! Is there anybody who can answer this? What always works is to make a simple logging procedure. This is nothing more than a procedure that opens the logfile, appends a string to it and closes it again. e.g. unit debuglog; interface uses dos; const debuglogger:boolean=true; const logfilename:pathstr='debuginf.txt'; procedure trace(s:string); Implementation procedure trace(s:string); var logfile:text; begin If debuglogger then begin assign(logfile,logfilename; append(logfile); writeln(logfile,s); close(logfile); end end; begin assign(logfile,logfilename); {$I-} rewrite(logfile); close(logfile); {$I+} debuglogger:= (IOerror=0); end. In the suspected code you can place commands like Trace('Now doing this'); Trace('the value of that param is' + ItoS(param) ); where ItoS is a funtion that uses var to convert Integer to String Advantage is that it has no troubles swapping between graphic and text mode. The program flow is not disturbed as the de{*filter*} does, which is important if there are time critical user inputs. You can get a nice print of the program flow. If it is a user program, you can ask the user to send you the logfile if the program crashes for an unknown reason at his computer. Disadvantage is of cource that you have to add extra commands in your code, that you need to have at least an idea of about where the error occurs. If you run it in pure Dos without smartdisk, the program may be seriously delayed if you place a Trace command in an iteration loop. On the other hand it tells you directly after how many iterations etc.. Femme Verbeek Quote: > I leave the field open for the local gurus to respond...
The best gurus are kangurus. (|-)
|
Tue, 04 May 2004 23:22:27 GMT |
|
|
Jason Burgo #9 / 12
|
debugging and protected mode
Quote: > You're right, they don't work the same way as an integrated de{*filter*} > when you can alter the source code, recompile right there, re run it, > etc.
That's very true. However adding TDX to your IDE "Tools" menu negates most of this inconvenience. Then there are the benefits, such as the wonderful object inspectors (Ctrl+I) and the ability to use a secondary mono monitor for the debug display. -- Jay Jason Burgon - Author of "Graphic Vision" GUI for DOS/DPMI === Free LFN capable Dos/WinDos replacement and === === New Graphic Vision version 2.12 available from: === http://www.*-*-*.com/
|
Tue, 04 May 2004 08:21:40 GMT |
|
|
Huub van Doore #10 / 12
|
debugging and protected mode
Femme Verbeek schreef: Quote: > I never managed to use the external de{*filter*}s to work in the same way as > the integrated one. > (or never tried hard enough). Somehow it displayed the contents of the > registers etc. which does not mean anything to me. Can any one write a > very short instruction how to get started with it. <snip> > Somehow the integrated de{*filter*} did never work in protected mode. <snip> > Is there a solution to this? > Femme Verbeek
This "display of contents of the registers", reminded me of something... Are you actually saying that it didn't display a main window with 7 or so sub-windows (registers, assembly, stack, etc)? Was there also some bla-bla about exception 12, 13 or bit granularity? If so, there might be a memory management problem. The above error is reported by HIMEM.SYS (or some other XMS-manager) IIRC. Meaning: DPMI was not invoked correctly (overlay files could not be found) or EMM386.EXE sits in the way. I do not recall the exact situation(s), this error occurred in, sorry.... Hoped to be of help. Huub.
|
Wed, 05 May 2004 04:16:12 GMT |
|
|
Markus Hum #11 / 12
|
debugging and protected mode
Quote:
>>You're right, they don't work the same way as an integrated de{*filter*} >>when you can alter the source code, recompile right there, re run it, >>etc. > That's very true. However adding TDX to your IDE "Tools" menu negates most of > this inconvenience. Then there are the benefits, such as the wonderful object > inspectors (Ctrl+I) and the ability to use a secondary mono monitor for the > debug display.
Under the TP7 and BP7 IDE the mono display can be used for textinput as well. Great for designing screens. Only one bug: the mousedriver doesn't handle this and the pointer is displayed on the VGA rather than the HCG so you don't know where you're clikcing...:-) Markus
|
Thu, 06 May 2004 02:04:59 GMT |
|
|
Jyrki Lahtone #12 / 12
|
debugging and protected mode
Quote:
> That's very true. However adding TDX to your IDE "Tools" menu negates most of > this inconvenience.
Please tell us, what params to give to TDX (in the menu) to do this right! I copied them from those of the real mode de{*filter*}, and suspect that this might explain some of the problems I have experienced. -- Jyrki Lahtonen, docent Department of Mathematics, University of Turku, FIN-20014 Turku, Finland http://www.*-*-*.com/ tel: (02) 333 6014
|
Fri, 07 May 2004 16:04:21 GMT |
|
|
|