D/B bit in data selectors and `ss` #1609

ecm-pushbx · 2022-03-28T21:25:31Z

ecm-pushbx
Mar 28, 2022

I noticed two oddities in dosemu2 lately, while creating tests for lDebug and FreeDOS Debug.

The first is that a selector's D/B bit (which indicates 32-bit code or stack size when set) is by default set by dosemu2. On HDPMI32 It is clear by default. Here is a test case. On dosemu2 it outputs:

Welcome to dosemu2!
    Build 2.0pre8-20191102-1332-g9cf2b7560
About to Execute : dpmioffs.com
About to Execute : dpmioffs.com
Protected mode breakpoint at 015Dh.
32-bit code segment breakpoint at 016Fh.
32-bit data selector (D bit 0) breakpoint at 01F3h.
32-bit data selector (D bit 1) breakpoint at 0216h.

Welcome in 32-bit protected mode.
Check null selector: The D bit is indeterminate.
Check allocated:     The D bit is set (1).
Check set base:      The D bit is set (1).
Check set limit:     The D bit is set (1).
Check D bit cleared: The D bit is clear (0).
Check D bit set:     The D bit is set (1).

The second is that dosemu2 appears to sometimes assume that the ss B bit is set (running in a 32-bit cs in DPMI). Here is the next test case. Output when run on its own, which is as expected:

Welcome to dosemu2!
    Build 2.0pre8-20191102-1332-g9cf2b7560
About to Execute : dpmistck.com
About to Execute : dpmistck.com
Protected mode breakpoint at 0211h.
32-bit code segment breakpoint at 0223h.
16-bit stack test breakpoint at 031Bh.
32-bit stack test breakpoint at 0339h.
Return from child process at 0450h.

Welcome in 32-bit protected mode.
Check allocated:     The D bit is set (1).
Check set limit:     The D bit is set (1).
Check set base:      The D bit is set (1).
DPMI allocation at 02121000h.
DPMI allocation selector is 00EFh.
Check D bit cleared: The D bit is clear (0).
ESP = 0001FFFCh, Trace Flag appears as clear (0).
Check D bit set:     The D bit is set (1).
ESP = 0000FFFCh, Trace Flag appears as clear (0).
Child process terminated okay, back in real mode.

Note that the first ESP = line indicates that the 16-bit sp underflowed without affecting the upper word of esp. This is the expected behaviour.

However, when tracing the 16-bit stack test with lDebugX then the full esp is used even though the B bit is clear:

Welcome to dosemu2!
    Build 2.0pre8-20191102-1332-g9cf2b7560
About to Execute : ldebugx.com /c='r dco or= 800' dpmistck.com
About to Execute : ldebugx.com /c='r dco or= 800' dpmistck.com
-r dco or= 800
-g
DPMI entry hooked, new entry=046C:8A66
Protected mode breakpoint at 0211h.
32-bit code segment breakpoint at 0223h.
16-bit stack test breakpoint at 031Bh.
32-bit stack test breakpoint at 0339h.
Return from child process at 0450h.

Unexpected breakpoint interrupt
AX=0200 BX=00E6 CX=0005 DX=000A SP=FFFC BP=0000 SI=070E DI=8A66
DS=220F ES=3210 SS=220F CS=220F IP=01D3 NV UP EI PL ZR NA PE NC
220F:01D3 89E5              mov     bp, sp
-rx
386 registers are displayed
-g 31B
Succeeded in unhooking interrupt 2Fh.
Welcome in 32-bit protected mode.
Check allocated:     The D bit is set (1).
Check set limit:     The D bit is set (1).
Check set base:      The D bit is set (1).
DPMI allocation at 02121000h.
DPMI allocation selector is 012Fh.
Check D bit cleared: The D bit is clear (0).
EAX=00000200 EBX=0000012F ECX=0001F300 EDX=0212100A ESP=0000FFFC EBP=0000FFFC
ESI=0000074C EDI=00000006 NV UP EI PL ZR NA PE NC
DS=00AF ES=00AF SS=012F CS=0107 FS=0000 GS=0000 EIP=0000031B
0107:0000031B 8ED3          mov     ss, ebx
0107:0000031D BC00000100    mov     esp, 00010000
#t
EAX=00000200 EBX=0000012F ECX=0001F300 EDX=0212100A ESP=00010000 EBP=0000FFFC
ESI=0000074C EDI=00000006 NV UP EI PL ZR NA PE NC
DS=00AF ES=00AF SS=012F CS=0107 FS=0000 GS=0000 EIP=00000322
0107:00000322 50            push    eax
#
EAX=00000200 EBX=0000012F ECX=0001F300 EDX=0212100A ESP=0000FFFC EBP=0000FFFC
ESI=0000074C EDI=00000006 NV UP EI PL ZR NA PE NC
DS=00AF ES=00AF SS=012F CS=0107 FS=0000 GS=0000 EIP=00000323
0107:00000323 89E1          mov     ecx, esp
#
EAX=00000200 EBX=0000012F ECX=0000FFFC EDX=0212100A ESP=0000FFFC EBP=0000FFFC
ESI=0000074C EDI=00000006 NV UP EI PL ZR NA PE NC
DS=00AF ES=00AF SS=012F CS=0107 FS=0000 GS=0000 EIP=00000325
0107:00000325 58            pop     eax
#
EAX=00000200 EBX=0000012F ECX=0000FFFC EDX=0212100A ESP=00000000 EBP=0000FFFC
ESI=0000074C EDI=00000006 NV UP EI PL ZR NA PE NC
DS=00AF ES=00AF SS=012F CS=0107 FS=0000 GS=0000 EIP=00000326
0107:00000326 9C            pushf
#
EAX=00000200 EBX=0000012F ECX=0000FFFC EDX=0212100A ESP=0000FFFC EBP=0000FFFC
ESI=0000074C EDI=00000006 NV UP EI PL ZR NA PE NC
DS=00AF ES=00AF SS=012F CS=0107 FS=0000 GS=0000 EIP=00000327
0107:00000327 5F            pop     edi
#
EAX=00000200 EBX=0000012F ECX=0000FFFC EDX=0212100A ESP=00000000 EBP=0000FFFC
ESI=0000074C EDI=00000246 NV UP EI PL ZR NA PE NC
DS=00AF ES=00AF SS=012F CS=0107 FS=0000 GS=0000 EIP=00000328
0107:00000328 0FB225780400
              00            lss     esp, [00000478]   DS:00000478=012F:0000FFFC
#

The esp value as saved in ecx indicates that the full 32-bit esp waa decremented.

ecm-pushbx · 2022-03-28T21:28:46Z

ecm-pushbx
Mar 28, 2022
Author

Hmm, odd. I just noticed that the 16-bit stack test in the debugger does increment esp from 0000FFFC to 00000000 upon the pop eax instruction. If it used the full esp consistently we would expect 00010000.

3 replies

stsp Mar 28, 2022
Maintainer

Please attach binary test-cases.
Is this with cpu-emu or kvm?

stsp Mar 28, 2022
Maintainer

I suspect high ESP word was just
zeroed, rather than been the subject
of decrementing.
Please don't misinterpret your results. :)

ecm-pushbx Mar 29, 2022
Author

I suspect high ESP word was just zeroed,

Oh true that might be so. Still odd that it happens when tracing in the debugger but not otherwise.

Test binaries are at https://pushbx.org/ecm/test/20220329/

How do I tell whether it is cpu-emu or kvm? The content of /proc/cpuinfo does list svm in the flags list.

stsp · 2022-03-29T12:40:10Z

stsp
Mar 29, 2022
Maintainer

Oh true that might be so. Still odd that it happens when tracing in the debugger but not otherwise.

Try $_cpu_vm_dpmi = "native" and see
if something changes.

How do I tell whether it is cpu-emu or kvm?

By looking into ~/.dosemu/boot.log.

0 replies

stsp · 2022-03-29T12:55:28Z

stsp
Mar 29, 2022
Maintainer

As for D bit: it simply matches
the bitness of a client, and DPMI
spec doesn't specify that explicitly.

0 replies

ecm-pushbx · 2022-03-29T16:09:22Z

ecm-pushbx
Mar 29, 2022
Author

Try $_cpu_vm_dpmi = "native" and see if something changes.

No change with -I "cpu_vm_dpmi native". With either -I "cpu_vm_dpmi kvm" (NB I found that there is no file /dev/kvm on this machine!) or -I "cpu_vm_dpmi emulated" the behaviour changes, both in the same way:

The high word of esp is cleared even when not singlestepping.
The dosemu -dumb screen output is interspersed by a bunch of messages reading ERROR: touched jit-protected page without a CR (LF only).
Upon termination of the dpmistck processes, lDebugX thinks that it is in 86 Mode but with the InDOS flag set. This is usually due to retaining the Protected Mode pointer to the flag, ie the debugger did not properly process the switch back to 86 Mode. I would have to inspect this further to be sure however.

As for D bit: it simply matches the bitness of a client, and DPMI spec doesn't specify that explicitly.

Allright, I suspected it may be underspecified. The new test "HUGESEG" of the original DebugX depends on the HDPMI32 behaviour for its intended purpose. However, I don't think dosemu2 has to do this the same way.

27 replies

ecm-pushbx Mar 30, 2022
Author

gdb is and was already installed:

$ gdb
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb)

Editing the src/include/emu.h to change that define to 1 then re-running make outputs the following while compiling signal.c: (Not sure whether it was there before, caught it by accident.)

signal.c:55:10: warning: #warning Not disabling SIGALTSTACK_WA, update your kernel
[-Wcpp]
   55 |         #warning Not disabling SIGALTSTACK_WA, update your kernel
      |          ^~~~~~~
signal.c:90:10: warning: #warning Not disabling SIGRETURN_WA, update your kernel [-
Wcpp]
   90 |         #warning Not disabling SIGRETURN_WA, update your kernel
      |          ^~~~~~~

The stack DPMI test works now:

dpmitest$ ~/local.new/bin/dosemu -K "$PWD" -dumb -E "dpmistck.com" -I "cpu_vm_dpmi native"
[...]
Welcome to dosemu2!
    Build 2.0pre9-dev-20220330-117-g84a8625f8
Protected mode breakpoint at 0211h.
32-bit code segment breakpoint at 0223h.
16-bit stack test breakpoint at 031Bh.
32-bit stack test breakpoint at 0339h.
Return from child process at 0450h.

Welcome in 32-bit protected mode.
Check allocated:     The D bit is set (1).
Check set limit:     The D bit is set (1).
Check set base:      The D bit is set (1).
DPMI allocation at 02122000h.
DPMI allocation selector is 00FFh.
Check D bit cleared: The D bit is clear (0).
ESP = 0001FFFCh, Trace Flag appears as clear (0).
Check D bit set:     The D bit is set (1).
ESP = 0000FFFCh, Trace Flag appears as clear (0).
Child process terminated okay, back in real mode.
Security warning: native DPMI mode is insecure, adjust $_cpu_vm_dpmi
ERROR: KVM: error opening /dev/kvm: No such file or directory
ERROR: PKT: Cannot open tap0: Permission denied
ERROR: PKT: Cannot open tap0: Permission denied
ERROR: alsa_midi (ALSA lib): seq_hw.c:466:(snd_seq_hw_open) : No such file or direc
tory open /dev/snd/seq failed
ERROR: MAP_FIXED_NOREPLACE doesn't work
ERROR: Unable to open console or check with X to evaluate the keyboard map.
Please specify your keyboard map explicitly via the $_layout option. Defaulting to
US.

NB there is single "ERROR: MAP_FIXED_NOREPLACE doesn't work" now but it doesn't endlessly repeat. And the high word of esp is not zeroed.

However, trying to debug the test with lDebugX failed one time when trying to display the 32-bit register dump, output is in https://pushbx.org/ecm/test/20220330.4 However this is not reliably reproduceable. It does sometimes happen, seemingly at random.

Otherwise, when tracing the execution with lDebugX I get esp high word as zero again. When proceeding past the test (using G command) it does preserve the high word.

Furthermore the debugger (in dosemu -dumb connected to DOS stdin/stdout) now repeats input lines once Enter is pressed, eg the prompt is - then entering rx<Enter> it displays:

-rx
-rx

And the up and down arrow keys don't arrive into the DOS stdin in the way expected by the debugger. This is all handled by lineio.asm, particularly in rawinput and getc. Entering <Up><Enter> at an empty prompt results in this output now:

-^[[A
-
-

Also, entering Control-C aborts the dosemu process with the last error output message being Terminated with signal 2

ecm-pushbx Mar 30, 2022
Author

Note that the debugger is started with /c='r dco or= 800' which makes it so rawinput and getc are used. The DOS interrupt 21h service 0Ah call is not used then. This enabled using the debugger's line edit and history features in dosemu -dumb mode previously.

stsp Mar 30, 2022
Maintainer

Please try again (w/o any mods).

I don't think you are attaching the log.
I think you are copy/pasting the screen
output instead!

If you need some non-dumb features,
then do not use -dumb. Use -td -kt
instead (compatible with any dosemu).

ecm-pushbx Apr 14, 2022
Author

Made a new issue for these crashes: #1615

ecm-pushbx Apr 14, 2022
Author

I also made a -dumb issue: #1614

ecm-pushbx · 2022-03-29T16:15:33Z

ecm-pushbx
Mar 29, 2022
Author

My partner confirms that this server doesn't have KVM available for our machine.

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

D/B bit in data selectors and `ss` #1609

{{title}}

Replies: 5 comments 30 replies

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

D/B bit in data selectors and ss #1609

ecm-pushbx Mar 28, 2022

Replies: 5 comments · 30 replies

ecm-pushbx Mar 28, 2022 Author

stsp Mar 28, 2022 Maintainer

stsp Mar 28, 2022 Maintainer

ecm-pushbx Mar 29, 2022 Author

stsp Mar 29, 2022 Maintainer

stsp Mar 29, 2022 Maintainer

ecm-pushbx Mar 29, 2022 Author

ecm-pushbx Mar 30, 2022 Author

ecm-pushbx Mar 30, 2022 Author

stsp Mar 30, 2022 Maintainer

ecm-pushbx Apr 14, 2022 Author

ecm-pushbx Apr 14, 2022 Author

ecm-pushbx Mar 29, 2022 Author

D/B bit in data selectors and `ss` #1609

ecm-pushbx
Mar 28, 2022

Replies: 5 comments 30 replies

ecm-pushbx
Mar 28, 2022
Author

stsp Mar 28, 2022
Maintainer

stsp Mar 28, 2022
Maintainer

ecm-pushbx Mar 29, 2022
Author

stsp
Mar 29, 2022
Maintainer

stsp
Mar 29, 2022
Maintainer

ecm-pushbx
Mar 29, 2022
Author

ecm-pushbx Mar 30, 2022
Author

ecm-pushbx Mar 30, 2022
Author

stsp Mar 30, 2022
Maintainer

ecm-pushbx Apr 14, 2022
Author

ecm-pushbx Apr 14, 2022
Author

ecm-pushbx
Mar 29, 2022
Author