Table of Contents
Recent segmentation in lDebug and not yet merged NASM patches
The lDebug debugger is a demanding application. It's driven NASM bug reports for a while now. There are 63 tickets filed by me in the NASM bugzilla, most of which cropped up during lDebug development. As described in 2022 July, the debugger's footprint has grown beyond 64 KiB segment limits twice now.
lDebug caught up with FreeDOS Debug, and ancient change log
As mentioned in the prior blog post
lDebug very much has a "go everywhere, do everything" theme.
Today we're caught up with FreeDOS Debug again for the most part.
(Still missing is the patch to use the test_high_limit function where appropriate.
It is nontrivial to decide which spots should use that function
instead of test_d_b_bit, which was renamed from testattrhigh.)
Conditionally Debuggable lDebug
The "go everywhere, do everything" theme of lDebug has gained a new feature: Conditionally Debuggable builds allow to switch between the non-debuggable mode (handlers are hooked when the debugger starts up and unhooked only when it terminates), and the debuggable mode.
In the debuggable mode, the prior debugger's handlers
are preserved in most of the debuggable application.
Only when calling the run function,
the debuggable debugger sets up its own handlers.
That means a great majority of the debuggable's code
can be debugged using another instance of lDebug.
Traditionally, FreeDOS Debug would require a lower-level debugger like one built into a virtual machine to be debugged. In recent years build options were added to never hook interrupts 1 (trace interrupt) and 3 (breakpoint interrupt), allowing to debug most parts. However, these options imply that you cannot actually run a debuggee and have it return control to the instance that is to be debugged.
lDebug, symbolic, and segment splits
The Return of the Symbolic Branch!
Recent comments by Bret Johnson caused me to revisit the symbolic branch of lDebug. These were one and two, referencing my earlier reply to this thread on DOS assembly language resources.
In particular, the second message ends in:
I also sometimes use ECM's lDebug, but that is mostly when I'm trying to figure out what someones else's program is doing and don't have the source code or some other way to look at the symbols/names to help try and figure out what's going on. lDebug is much better/easier than D86/D386 for certain kinds of debugging/research.
So, the natural reaction is to consider: what is lDebug not (yet!) better and easier for than the competition? (Mind, I didn't actually ask Bret about this yet.)
mov fast and mak things
‘Move fast and break things’ is a development mantra popularised by Facebook and picked up with enthusiasm by software development teams both small and large. The idea is that if you aren’t breaking things you’re delivering value too slowly.
Why 'Move Fast and Break Things' Doesn’t Work, capacitas Insights (also in the Internet Archive)
mov is of course an 8086 instruction,
and mak is a script name for build scripts that I tend to use, most intricately to build lDebug.
