DOS IDE Debugger

[Dmitry24]

I cannot use the FPC IDE integrated debugger for DOS since FPC 2.X  (stepping, tracing, etc. as it craches, hangs). So I'm still using FPC 1.0.X for this purpose. With the new FPC release 3.2.X I can see there are some signs of life of the internal debugger but it still fails if the source file size is larger than a couple of KB (even if there is just one intruction and other context are comments).

I wonder if DOS IDE debugging is in real development or it is just some dummy/obsolete functionality. Is it in use by someone? Should I report bugs, etc. (I cannot find any bugtracker reports regarding DOS IDE debugger).

I found GDB libgdb libraries v7.7.1 for compiling DOS IDE with debugger support here:
ftp://ftp.freepascal.org/pub/fpc/contrib/libgdb/

Suprisingly they are recently updated (29.03.2020) however GDB version is not actual (AFAIK there is already GDB v9.1 released on Feb, 8th, 2020, but I don't know how to compile new libgdb files for FPC IDE).

I can see Debugging on other platforms became really stable (especially with the use of MI interface still not supported in DOS). Is there any information on plans regarding the FPC IDE debugger for DOS? Maybe some help is needed? Or nobody is really interesed.

[PascalDragon]

Just for clarification: are you simply talking about the TextMode IDE or are you talking about using the IDE on DOS?

[Dmitry24]

I mean using on real DOS (not console/terminal box). Maybe I'm writing in the wrong section.

[PascalDragon]

No, the section is alright. It's just that many people call the TextMode IDE “DOS IDE” without wanting to use it on DOS.

I think one of the problems is that it's rather hard to get the GDB build system to build the static library nowadays (that's why we introduced the GDBMI interface with 3.2 for targets that can make use of it).

You could try whether you can reproduce your crashes with a standalone GDB to pinpoint whether it's a problem of GDB in general or of the static library or the way the TextMode IDE uses the debugger...

[Dmitry24]

Is MI Interface can be supported in DOS? It is possible to compile IDE for DOS with GDBMI option but this IDE even cannot start debugging and halts.

Regarding the source of the problem I found FPC IDE compiled in debug mode a bit more stable but this doesn't yet allow concluding the problem is with FPC.

I just tried a standalone DOS debugger v.6.11 I was able to find within FPC packages (thank you for suggestion) but I'm not sure if it is working at all. When I try stepping it hangs always. At the same time there is at least some success with integrated libraries for the GDB v.7.7.1 but I cannot find their standalone version.

Could you please suggest where I can find a newer DOS version of the debugger for DOS? The libraries v.7.7.1 were generated somehow: ftp://ftp.freepascal.org/pub/fpc/contrib/libgdb/

[PascalDragon]

Is MI Interface can be supported in DOS? It is possible to compile IDE for DOS with GDBMI option but this IDE even cannot start debugging and halts.

I can't see how. It would probably be more complex and fragile than the static library due to DOS being a single tasking operating system.

I just tried a standalone DOS debugger v.6.11 I was able to find within FPC packages (thank you for suggestion) but I'm not sure if it is working at all. When I try stepping it hangs always. At the same time there is at least some success with integrated libraries for the GDB v.7.7.1 but I cannot find their standalone version.

Could you please suggest where I can find a newer DOS version of the debugger for DOS? The libraries v.7.7.1 were generated somehow: ftp://ftp.freepascal.org/pub/fpc/contrib/libgdb/

I'm not working with DOS, so I don't know. You could try whether FreeDOS comes with a newer version.

[Dmitry24]

I figured out how to run the standalone GDB debugger and yes, it allows stepping normally (at least the available version 6.11) regardless the program complexity.

While FPC integrated debugger hangs on stepping the program as soon as current source file size is larger than several tens of KBytes (even if there is just a single instruction except comments).

Previously I specified wrongly. The threshold size for the bug is approx. 20 KBytes.

[PascalDragon]

Then the question now is whether it's a fault of the static library or of the way the TextMode IDE uses it.

The static library is imported through %fpcdir%\packages\gdbint\src and the IDE's debugger interface is in %fpcdir%\packages\ide\fpdebug.pas. You could maybe try to write a simple debugger interface for the static library and test whether this works correctly. Maybe this way one can find out the problem on DOS.

[marcov]

I checked, and there are two unmerged gdbint revisions:  44471,44774

r44471 | pierre | 2020-03-31 22:49:17 +0200 (Tue, 31 Mar 2020) | 9 lines
Changed paths:
   M /trunk/packages/gdbint/src/gdbint.pp

  Try to fix problems for more recent GDB versions.
  Move GDB_NEW_UI macro def. to GDB_VER_GE_712
  Add GDB_INTERP_LOOKUP_HAS_UI and GDB_HAS_SAVED_COMMAND_LINE_BUT_NO_SIZE
  to same GDB_VER_GE_712.
  Use stdio_filopen to create gdb_stdout and gdb_stderr
  if GDB_HAS_GET_STDIN macro is set.
---
r44774 | pierre | 2020-04-18 11:53:24 +0200 (Sat, 18 Apr 2020) | 4 lines
Changed paths:
   M /trunk/packages/gdbint/src/gdbint.pp

  * Fix compilation of gdbint unit for go32v2, should resolve bug report 36923.
    Replace cint type by longint (as gdbint unit does not use ctypes unit).

[Dmitry24]

Finally I found out that changing DOS extender (cwsdpmi.exe of any version) to another one (hdpmi32.exe) resolved the problem (and FPC version does not matter at the moment).

AFAIK there are different issues regarding DOS exteneded memory usage on modern PC's. What run on one PC may fail on another. I'm afraid the real issue is too complex...