debugging and protected mode 
Author Message
 debugging and protected mode

Why doesn't work the de{*filter*} in protected mode ?

nb



Sun, 02 May 2004 05:58:14 GMT  
 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  
 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  
 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  
 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  
 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  
 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:

> Femme Verbeek

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  
 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  
 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  
 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  
 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  
 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  
 
 [ 12 post ] 

 Relevant Pages 

1. debug in protected mode

2. F7+F8 Debug in protected mode. How ?

3. 'Delphi does dos' - compile and debug BP7 protected mode programs under D1.

4. Debugging in the IDE in protected mode?

5. No debugging available in Protected Mode?

6. CRASH in debug mode (not in design mode) / access to DB

7. Protected mode VS Real mode ???

8. Real Mode from Protected Mode: Accessing an RMode TSR from PMode

9. Protected mode vs. Real mode

10. Vesa unit for all 256 and 65K color modes (protected,real mode)

11. Real mode Interrupts and pointers in Protected Mode

12. Real mode > protected mode, BGI error :-(

 

 
Powered by phpBB® Forum Software