Differences

This shows you the differences between two versions of the page.

--- blog:pushbx:2023:0903_august:september_work [2023-09-03 18:14:53 +0000 Sep Sun] – created ecm
+++ blog:pushbx:2023:0903_august:september_work [2023-12-04 19:47:07 +0000 Dec Mon] (current) – [Notes from debugging lDebug] ecm
@@ Line 98: / Line 98: @@
 The workaround is to run a single run command (T, TP, P, or G -- but not TTEST) before enabling the breakpoint on the interrupt 2Dh entrypoint. This will give the debugger the chance to hook the DPMI entrypoint before the breakpoint is enabled.
-Another choice would be to ''uninstall int2F'' before setting the breakpoint. In particular, if no DPMI host is installed the debugger may retry the DPMI entrypoint hook on every run instruction. However, it seems that this won't actually work because the DCO4 flag is checked too late into the function, where the int 2Dh and int 2Fh calls already happened.
+Another choice would be to ''uninstall int2F'' before setting the breakpoint. In particular, if no DPMI host is installed the debugger may retry the DPMI entrypoint hook on every run command. However, it seems that this won't actually work because the DCO4 flag is checked too late into the function, where the int 2Dh and int 2Fh calls already happened.
@@ Line 117: / Line 117: @@
   * (In outer debugger:)
   * Enter a TSR command
-  * Enter a G comman
+  * Enter a G command
   * (On the DOS command line:)
   * Run a ''keephook 8'' command
@@ Line 131: / Line 131: @@
 A similar trick was used [[blog:pushbx:2023:0828_late_august_work#freedos_kernel|to debug the FreeDOS kernel bug]] in order to load the second debugger near the top of the Low Memory Area. This also had the second debugger run a TSR command then a G command, returning to the PRA of the first debugger in the debuggee context of the second debugger. In that case, the first debugger was simply quit to leave only the second debugger resident.
-{{tag>edrdos testhook ldebug}}
+{{tag>edrdos testhook ldebug heatshrink}}
 ~~DISCUSSION~~