This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Trouble tracing jump from real to protected mode with gdb
- From: fpga <mgbg25171 at blueyonder dot co dot uk>
- To: gdb at sourceware dot org
- Date: Wed, 28 Oct 2009 05:58:25 -0700 (PDT)
- Subject: Trouble tracing jump from real to protected mode with gdb
Here's an embedded image snippet that switches into protected mode....
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
Tracing it using gdb is problematic
ie 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 on the mem dump similarly gets out of synch too.
To get the right result I have to specify 0x208
(ie where far jump appear to go to) manually....
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
How can I tell gdb to do this so that lret doesn't creep in and move the
instructions way past 0x208
Thx in anticpation
--
View this message in context: http://www.nabble.com/Trouble-tracing-jump-from-real-to-protected-mode-with-gdb-tp26094206p26094206.html
Sent from the Sourceware - gdb list mailing list archive at Nabble.com.