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??
they are 16-bit instructions with size over-rides
66h and 67h are size over-ride opcodes
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.