News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

trouble tracing switch from real to protected mode

Started by bobl, October 28, 2009, 03:38:41 PM

Previous topic - Next topic

bobl

In my last post I posted this code
                   mov eax, cr0
                   or al, 1         
                   mov cr0, eax
                   jmp cseg:goforth   <16bit here
[BITS 32]                 
goforth:     mov ax, dseg       <32bit here
                   mov ds, ax       

The code runs fine. Its tracing it thats the problem
ie using gdb with architecture set as i8086 gdb gives ...

Breakpoint 3, 0x00000203 in ?? ()
0x00000203: jmp    0x8:0x208
0x00000288: iret 
0x0000028c: add    BYTE PTR [bx+si],al
etc

and with architecture set as i386:intel gdb gives ...

Breakpoint 3, 0x00000203 in ?? ()
0x00000203: jmp    0xb866:0x80208     <=====jmp cseg:goforth
0x00000288: iret                   
0x0000028c: add    BYTE PTR [eax],al


Using ht, ida or ndisasm gives me the right result only if, in 32bit mode, I INSIST on "synching" at address of  0x208 suggested by the above jump offset
ie ndisasm -o 0x0000 -s 0x208 dump_at_203 -b 32 >result

00000208  66B81000          mov ax,0x10   
0000020C  668ED8            o16 mov ds,ax
0000020F  668ED0            o16 mov ss,ax
00000212  668EC0            o16 mov es,ax

I can see that switching from 16 to 32 bit is going to trip things up somehow with the change of word size but the uninvited appearance of iret means we sail way past 208 in gdb so that even if the architecture was reset to i386:intel immediately after the far jump I'm still not going to see 0x208

Any thoughts most welcome

BTW How come I'm seeing what looks like 16 bit instructions (o16) in what should be protected mode. Is this normal??

dedndave

they are 16-bit instructions with size over-rides
66h and 67h are size over-ride opcodes

bobl

That helps

It helps cos I don't suppose gdb in i8086 mode would "know" what that prefix means suggesting that gdb has to be in i386 mode to disassemble such an instruction even though its 16bit.

I could re-specify the architecture as i386 after the far jump but that wont help @ present cos iret is obscuring the instruction @ 0x208.

I've asked on the gdb forum before starting this thread how I could re-sync gdb but no posts so far

Thx very much for pointing it out.