[vbox-dev] Debugging with wrapped 32 bit physical address

[Slavik Gnatenko]

Hi All!

I took VBox 4.2.6 to work with fork of OS/2 kernel. At early init stage this 
kernel uses quite unusual addressing:
- CPU is in protected mode but paging is NOT enabled
- segments are mainly 4GiB in size but with not zero base
- offsets are near end of 4GiB. So physical address is wrapped to the 
beginning of memory

Such mode seems to be supported by VM but I see several problems.

1) Debugger refuses to decompile the code. I suspect that it calculates 
physical address as 64 bit and doesn't wrap it. Here is the debug session 
snippet which shows that even simple "db" doesn't read the memory:
VBoxDbg> rg
eax=0000000a ebx=ffed53fb ecx=ffe41f42 edx=000003f8 esi=ffdf0100 edi=ffe41f2a
eip=fffa2da6 esp=0000cf1e ebp=0000cf9a iopl=0 rf nv up di pl nz na pe nc
cs=0178 ds=0170 es=0170 fs=0000 gs=0000 ss=2a48               eflags=00010002
Failed to disassemble instruction, skipping one byte.
u: error: Too many disassembly failures. Giving up: VINF_SUCCESS

VBoxDbg> db cs:eip
error: VERR_PGM_INVALID_GC_PHYSICAL_ADDRESS:  Reading memory at 0178:fffa2da6

But this memory can be read and disassembled if physical address is 
calculated by hands:

VBoxDbg> dg 178
0178 CodeER Bas=0024d000 Lim=fffff000 DPL=0 P  A  G BIG AVL=0 L=0
VBoxDbg> db %(24d000 + fffa2da6)
error: VERR_PGM_INVALID_GC_PHYSICAL_ADDRESS:  Reading memory at 
%00000001001efda6.
VBoxDbg> db %(24d000 + fffa2da6 - 100000000)
%00000000001efda6: 83 3d 88 0a 80 ff ff 75-13 be 01 00 00 00 87 35 
.=.....u.......5
%00000000001efdb6: c0 2a ed ff f7 c6 01 00-00 00 75 ed 8b 74 24 08 
.*........u..t$.
%00000000001efdc6: 66 9c fc 33 c0 ac 0a c0-74 09 50 e8 c1 ff ff ff 
f..3....t.P.....
%00000000001efdd6: 58 eb f0 83 3d 88 0a 80-ff ff 75 08 33 f6 87 35 
X...=.....u.3..5
%00000000001efde6: c0 2a ed ff 66 9d 5e c3-56 8b 74 24 08 66 9c fc 
.*..f.^.V.t$.f..
%00000000001efdf6: 33 c0 ac 0a c0 74 1a 3c-0a 75 09 66 3d 0a 0d 74 
3....t.<.u.f=..t
VBoxDbg> u %(24d000 + fffa2da6 - 100000000)
%00000000001efda6 83 3d 88 0a 80 ff ff    cmp dword [0ff800a88h], byte 
0ffffffffh
%00000000001efdad 75 13                   jne +013h (0001efdc2h)
%00000000001efdaf be 01 00 00 00          mov esi, 000000001h
%00000000001efdb4 87 35 c0 2a ed ff       xchg dword [0ffed2ac0h], esi
%00000000001efdba f7 c6 01 00 00 00       test esi, 000000001h
%00000000001efdc0 75 ed                   jne -013h (0001efdafh)
%00000000001efdc2 8b 74 24 08             mov esi, dword [esp+008h]
%00000000001efdc6 66 9c                   pushfw
%00000000001efdc8 fc                      cld
%00000000001efdc9 33 c0                   xor eax, eax
	
Is it known bug? Is it possible to force debugger to use 32 bit arithmetic?

-------------------------------------------------------------------------

2) Now let's look to "cmp dword [0ff800a88h], byte 0ffffffffh" instruction 
at which the VM is stopped with fatal error:
VBoxDbg>
dbf event: Fatal error! (hyper)
.eax=00000000 .ebx=00000000 .ecx=00000000 .edx=00000000 .esi=00000000 
.edi=00000000
.eip=00000000 .esp=ff560000 .ebp=00000000 .iopl=0 nv up di pl nz na pe nc
.cs=fff8 .ds=fff0 .es=fff0 .fs=0000 .gs=0000 .ss=fff0 
.eflags=00000000
Failed to disassemble instruction, skipping one byte.
u: error: Too many disassembly failures. Giving up: VINF_SUCCESS
VBoxDbg> db %(24d000 + ff800a88)
error: VERR_PAGE_NOT_PRESENT:  Reading memory at %00000000ffa4da88.

Yeah. We really have no memory at this address. But is it intentional 
feature to completely stop a VM in this case? On real hardware such reading 
doesn't cause problems. And I suspect that such VM behavior breaks a code 
which searches for physical memory or specific ROM extension by scanning of 
wide range of possible addresses. Is this feature configurable?


-------------------------------------------------------------------------

3) And the related but may be separate topic. Should bp/br do something more 
than just patching the code and add the breakpoint to "bl" output? Even in 
simple real mode of CPU I don't get VBox debugger popup when control goes 
via these breakpoints. And even worse the injected "int3" is executed 
completely in the guest and previous command at this address is lost.

This is all for now. I think that many of these weird things should be filed 
as bugs but let's discuss them before this.

Regards, Slavik