Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to index page
Thread view  Board view
ecm

Homepage E-mail

Düsseldorf, Germany,
08.03.2024, 19:29
 

lDebug release 8 (Announce)

(Copied from freedos-user mailing list announcement.)

Hello list.

Here's another release of lDebug (with a small L). This application is an advanced line-oriented debugger for 86-DOS alike systems. It can be loaded instead of a DOS kernel (bootloaded), as a device driver, or as a DOS application. The DOS uses may attach or detach from processes using the ATTACH and TSR commands respectively, adding the resident debugger mode to the normal use as a DOS application. There is a build included in the release which supports running as a DPMI client to debug another DPMI client.

This is a bugfix and incremental release after last month's release 7 [1]. A few highlights of what changed:

Release packages do not contain listing files any longer. Some temporary files are also deleted after building This saves a lot of space for all the build packages except for the SvarDOS binary-only package. One reason for dropping the listings is that the debugger main listing as well as the Extension for lDebug listings are not particularly useful with a non-debuggable build of the debugger, which is the only build provided with the release.

If desired, the listing files can be obtained in two ways: Either by running (from ldebug/source/) "./make reproduce" and "./makinst.sh" and (from ldebug/source/eld/) "./mak.sh", or by downloading yesterday's [2] or today's [3] current builds from our server. (Today's current build is not yet available but will be created later today before midnight in the +0100 timezone.) We have ensured that the map files and listing files for these builds are almost exactly the same, excepting the text contents of some version strings of the main debugger executable. One of the bugfixes in release 8 concerns filling the AMIS description message to avoid differing offsets due to a difference in the message length.

Another fix involves running the debugger as a device driver. During initialisation of this mode, the debugger can accept command line switches. However, specifying a program name to load is invalid for the device mode debugger before an ATTACH command ran successfully. When such a name is provided on the command line, it will now display an error message that reads "Cannot terminate attached while resident." instead of crashing the kernel [4].

Another set of bugs fixed involves the drive locking needed to write sectors to a drive on MS-DOS v7 and v8. The first bugfix is that the correct drive is now unlocked after the write operation, rather than a random one. The second bugfix is that the lock and unlock calls are also done on MS-DOS v7.00 (from the original MSW 95), which has the locking feature (to protect its LFNs) but does not use the new style disk packet interface (for FAT32 drives) introduced in MS-DOS v7.10 (corresponding to a later MSW 95 revision and MSW 98).

I also attempted to add a way to preserve the current lock state of a drive before locking it for writing, but this turned out not to work (at least not in pure MS-DOS mode without MSW running). As this failed, the debugger will now unconditionally unlock a drive after it wrote a sector. (This was the intended mechanism for this, but did not work correctly prior to the bugfixes.)

Another change is that the compressed executables now default to support depack progress displays. This defaults to a dots display for bootloaded mode and no display for device driver and application mode. For the DOS modes (that is, not bootloaded mode) setting the environment variable %LDEBUGPROGRESS% allows to select a different progress display choice.

The defaults for the progress display can be patched in the inicomp (depacker) stage. Newly provided C programs [5] can be used to patch both the inicomp progress display choices as well as the query patch site in the iniload boot loading stage [6]. Unlike the earlier patch Script for lDebug shipped with ldosboot, these programs can be used even when arbitrary data is appended to the debugger executables. The provided build contains DOS executables compiled from the C sources using tkchia's gcc for 8086 DOS targets. However, the C sources can be compiled for direct use on other platforms as well.

Another bug that got fixed was likely introduced during the reorganisation of the Script for lDebug and Extension for lDebug loaders when ELDs were added and refined. In bootloaded mode, a "Y :label" command within a Script for lDebug file would not work any longer. This command is used to "call" a different part of the same Script for lDebug file that is already running.

Finally, the test suite was adapted and verified to run to completion correctly for lDebug, lDebugX, lDDebug, lDDebugX, and lCDebugX (all both in bootloaded or application mode). The ELD comparison program was also run on all registered ELD test install commands [7] and test run commands [8]. The testing did turn up the Y bug described in the previous paragraph as well as two wrong relocations in the dpb.eld utility [9].

As usual, all the news in the manual [10] and even grittier details in the hg repo [11]. Release packages are provided on our server [12], including the FreeDOS and SvarDOS packages in the subdirectories. All links are listed on my website too [13]. As the news blurb I would suggest the following:

New lDebug release 8

The lDebug debugger (spelled with a small L) is a line-oriented DOS debugger based on FreeDOS Debug/X, originating as an MS-DOS Debug clone. Release 8 is a maintenance release with some bugfixes, testing updates, new progress displays for the executable depackers, and a smaller release sources archive achieved by dropping temporary and listing files, and building only ELDs without the XLD variants. The lDOS boot iniload and inicomp stages can be patched using new utilities provided as C programs. For more details, see the [email list announcement] [14] or find "everything lDebug" at [the lDebug website] [13]. We've also mirrored this release at the FreeDOS Files Archive at Ibiblio, under [/dos/debug/ldebug]

Regards,
ecm


[1]: https://sourceforge.net/p/freedos/mailman/message/58738462/
[2]: https://pushbx.org/ecm/download/old/ldebug/20240307.zip
[3]: https://pushbx.org/ecm/download/old/ldebug/20240308.zip
[4]: https://github.com/FDOS/kernel/issues/142
[5]: https://pushbx.org/ecm/download/patchini.zip
[6]: https://pushbx.org/ecm/doc/ldosboot.htm#protocol-sector-iniload-patch
[7]: https://hg.pushbx.org/ecm/ldebug/rev/46084a0129f1
[8]: https://hg.pushbx.org/ecm/ldebug/rev/fae67d061195
[9]: https://hg.pushbx.org/ecm/ldebug/rev/95eef5ab0eb4
[10]: https://pushbx.org/ecm/doc/ldebug.htm#news-r8
[11]: https://hg.pushbx.org/ecm/ldebug/log/release8
[12]: https://pushbx.org/ecm/download/ldebug/
[13]: https://pushbx.org/ecm/web/#projects-ldebug
[14]: insert link to mailing list announcement in the freedos-user archives

---
l

Japheth

Homepage

Germany (South),
10.03.2024, 10:40

@ ecm
 

lDebug release 8

> Here's another release of lDebug (with a small L).

Very nice!

If you always have to explain the "little l", you should perhaps rename the debugger :-D It might become tedious.

> Another set of bugs fixed involves the drive locking needed to write sectors to
> a drive on MS-DOS v7 and v8. The first bugfix is

I also once "played" with the "drive locking" thing when modifying WDe, but my impression is, it's a big sh*t - don't want to mess with that again.

-------

I tried ldebugx with a current test case ( LFN support of Open Watcom v2.0 ). It stops at the breakpoint in protected-mode, but at the end, when the program already has "finished", it gives a GPF ( presumably in the debugger itself ).

Here's the test case if you want to take a look yourself: https://github.com/Baron-von-Riedesel/Testcases/tree/main - It's the hello.zip file, the binary is hello.exe.

---
MS-DOS forever!

roytam

10.03.2024, 11:53

@ Japheth
 

lDebug release 8

> > Another set of bugs fixed involves the drive locking needed to write
> sectors to
> > a drive on MS-DOS v7 and v8. The first bugfix is
>
> I also once "played" with the "drive locking" thing when modifying WDe, but
> my impression is, it's a big sh*t - don't want to mess with that again.

IIRC PC DOS 7.1 supports "drive locking" as well but its COMMAND.COM doesn't have it.
I wonder if it is good to write a standalone LOCK utility.

ecm

Homepage E-mail

Düsseldorf, Germany,
10.03.2024, 15:02

@ Japheth
 

lDebug release 8

> > Here's another release of lDebug (with a small L).
>
> Very nice!
>
> If you always have to explain the "little l", you should perhaps rename the
> debugger :-D It might become tedious.

Nevah!

> > Another set of bugs fixed involves the drive locking needed to write
> sectors to
> > a drive on MS-DOS v7 and v8. The first bugfix is
>
> I also once "played" with the "drive locking" thing when modifying WDe, but
> my impression is, it's a big sh*t - don't want to mess with that again.

I traced through the (DOS) kernel code that handles the lock and unlock. Neither of the "query lock" functions documented in the Interrupt List is implemented in the DOS kernel so the only way to get the current lock status is to peek into the kernel's internal structures for the lock flags.

> -------
>
> I tried ldebugx with a current test case ( LFN support of Open Watcom v2.0
> ). It stops at the breakpoint in protected-mode, but at the end, when the
> program already has "finished", it gives a GPF ( presumably in the debugger
> itself ).
>
> Here's the test case if you want to take a look yourself:
> https://github.com/Baron-von-Riedesel/Testcases/tree/main -
> It's the hello.zip file, the binary is hello.exe.

Thanks for the report! Should be fixed now: https://hg.pushbx.org/ecm/ldebug/rev/5f4daee63025

The problem was that my function entry_to_code_sel assumed a 16-bit stack. This function is part of the data code split (mentioned on the blog) which made it so the entry segment is not equal to the code segment, so they need to be addressed with different selectors as well. I fixed this by first switching stacks before using the function.

Writing of which, I checked all uses of this function. I think the only case that may still have a 32-bit stack is in the exception handlers: https://hg.pushbx.org/ecm/ldebug/file/92ea23f12b9d/source/pmentry.asm#l213

Can a DPMI exception handler be called with a 32-bit stack? Seems like it is possible, but for dosemu2 and HDPMI it seems like the stack is either 16-bit or ESPH is zero, as a build with _PM_ENTRY_SECTION=0 works as expected.

---
l

ecm

Homepage E-mail

Düsseldorf, Germany,
10.03.2024, 15:25

@ ecm
 

lDebug release 8

> Writing of which, I checked all uses of this function. I think the only
> case that may still have a 32-bit stack is in the exception handlers:
> https://hg.pushbx.org/ecm/ldebug/file/92ea23f12b9d/source/pmentry.asm#l213
>
> Can a DPMI exception handler be called with a 32-bit stack? Seems like it
> is possible, but for dosemu2 and HDPMI it seems like the stack is either
> 16-bit or ESPH is zero, as a build with _PM_ENTRY_SECTION=0
> works as expected.

Added a build option to check this: https://hg.pushbx.org/ecm/ldebug/rev/f8cde3f9652d

Both dosemu2 and HDPMI appear to set the ss B bit but leave esph as zero.

---
l

Japheth

Homepage

Germany (South),
11.03.2024, 10:47

@ ecm
 

lDebug release 8

> Both dosemu2 and HDPMI appear to set the ss B bit but leave esph as zero.

Yes. Win9x has problems with hiword(esp) of 16-bit stacks trashed in ring0 - I definitely wanted to avoid that, although the ring0 ss segment in hdpmi needs access to both dos memory and host memory ( which is > 0xff800000 ).

It was fixed by mapping the few needed conv. memory pages into the host address space; that "double" mapping causes a measurable speed penalty, btw.

---
MS-DOS forever!

ecm

Homepage E-mail

Düsseldorf, Germany,
11.03.2024, 09:30

@ Japheth
 

lDebug release 8

> I tried ldebugx with a current test case ( LFN support of Open Watcom v2.0
> ). It stops at the breakpoint in protected-mode, but at the end, when the
> program already has "finished", it gives a GPF ( presumably in the debugger
> itself ).
>
> Here's the test case if you want to take a look yourself:
> https://github.com/Baron-von-Riedesel/Testcases/tree/main -
> It's the hello.zip file, the binary is hello.exe.

The fix changeset I linked has landed in the current build so the lDebugX in that build should not crash like that any longer: https://pushbx.org/ecm/download/old/ldebug/20240310.zip

---
l

Back to index page
Thread view  Board view
22049 Postings in 2034 Threads, 396 registered users, 33 users online (0 registered, 33 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum