Is this far jump screwing up my trace

[bobl]

I'm tracing my way through some code running under qemu controlled by gdb.
The snippet shows a far jump to protected mode, judging by [BITS 32] & protected i.e.

Code Select Expand


   421                                  gdt0:
   422 00000038 0000000000000000        dw 0, 0, 0 ,0
   423                                  code equ $-gdt0



   452                                 
   453                                  relocated:
   454 00000080 260F0116[2E00]          lgdt [es:gdt]
   455 00000086 B001                    mov al, 1
   456 00000088 0F22C0                  mov cr0, eax
   457 0000008B EA[9000]0800            jmp code:protected    <=====debugger seems to lose it after this jump
   458                                 
   459                                  [BITS 32]
   460                                  protected:
   461 00000090 B010                    mov al, data


Tracing up to line 457 is predictable but once I execute the jmp above gdb seems to "lose the plot" as shown below i.e.

Code Select Expand


Breakpoint 4, 0x0000008b in ?? ()
(gdb) disassemble (($cs<<4)+$eip) (($cs<<4)+$eip+1)
Dump of assembler code from 0x8b to 0x8c:
0x0000008b: jmp    0x8:0x90
End of assembler dump.
(gdb) nexti
0x00000090 in ?? ()
(gdb) disassemble (($cs<<4)+$eip) (($cs<<4)+$eip+1)
Dump of assembler code from 0x110 to 0x111:
0x00000110: shl    al,1     <============== I thought this would be 'mov al, data' to fit addr 0x00000090  i.e. 3 lines up
End of assembler dump.                                                                                                                           
(gdb) dump binary memory /home/me/ramdump 0x0 0x1ff
(gdb)


The debugger has correctly disassembled the line according to the listing file i.e.
   527 00000110 D0E0                       shl al, 1    ; check high bit (1 = data ready)
but this instruction is way past the one that I thought should happen immediately after the jump i.e.
   461 00000090 B010                       mov al, data

(Note the code got relocated to start @ 0 so ram & listing addresses are the same).

The ramdump taken after the jmp looks like this

Code Select Expand


00000000 eb 52 90 63 6d 63 66 20-31 2e 30 00 02 01 01 00 |?R?cmcf 1.0 ??? |   ^
│00000010 02 e0 00 40 0b f0 09 00-12 00 02 00 00 00 00 00 |?? @??? ? ?     |   ▒
│00000020 40 0b 00 00 00 00 00 00-00 01 02 12 1b ff 17 00 |@?       ?????? |   ▒
│00000030 38 00 00 00 04 00 00 00-00 00 00 00 00 00 00 00 |8   ?           |   ▒
│00000040 ff ff 00 00 00 9a cf 00-ff ff 00 00 00 92 cf 00 |??   ?? ??   ?? |   ▒
│00000050 00 4c 09 00 b8 02 4f bb-17 41 cd 10 fa 66 31 c0 | L? ??O??A???f1?|   ▒
│00000060 66 8c cb 8e db 8e c0 66-89 c7 66 89 c6 e8 00 00 |f??????f??f???  |   ▒
│00000070 5e 81 ee 70 00 b9 80 00-f3 66 a5 ea 80 00 00 00 |^??p ?? ?f???   |   ▒
│00000080 26 0f 01 16 2e 00 b0 01-0f 22 c0 ea 90 00 08 00 |&???. ???"??? ? |   ▒
│00000090 b0 10 8e d8 8e c0 8e d0-bc 00 00 0a 00 31 c9 b0 |?????????  ? 1??|   ▒
│000000a0 d1 e6 64 e4 64 24 02 75-fa b0 4b e6 60 b8 ff 47 |??d?d$?u??K?`??G|   ▒
│000000b0 00 00 e8 d1 00 00 00 c1-e3 04 01 de 81 3e 44 44 |  ??   ??????>DD|   ▒
│000000c0 44 44 75 08 66 b9 80 3e-f3 a5 eb 1e 31 ff e8 00 |DDu?f??>????1?? |   
│000000d0 01 00 00 fe 05 27 00 00-00 8a 0d 34 00 00 00 fe |?  ??'   ??4   ?|   
│000000e0 c9 51 e8 ec 00 00 00 59-e2 f7 e8 7f 00 00 00 be |?Q??   Y????   ?|   
│000000f0 00 f4 09 00 f1 b0 1c e8-7e 00 00 00 b9 c0 68 78 | ?? ????~   ??hx|   
│00000100 04 e2 fe b0 07 b1 02 eb-58 66 ba f4 03 ec e6 e1 |????????Xf??????|   
│00000110 d0 e0 73 f9 42 84 c0 c3-8d 15 25 00 00 00 88 02 |??s?B?????%   ??|   


You can see that addr 0x90 has the bytes 'b0 10' which match the instruction...   
461 00000090 B010                       mov al, data'

Can someone please explain the flaw in my understanding of this situation.
Thx

[dedndave]

what you are probably observing is that the processor won't let you trace through a mode switch
i am no expert on switching modes, but that would make sense
to know you got as far as the SHL AL,1 instruction is going to have to be good enough
the debugger should allow you to see the contents of AL, so you can see that the MOV AL,data happened
if you look in the manual, it will probably tell you that the "trace" or "single-step" flag gets cleared during the switch

[sinsi]

You should try using Bochs - it has a built-in debugger which will trace everything, even the BIOS code from a cold reset.
It's really good for seeing why code triple-faults and where.

[bobl]

On the strength of your responses I'm switching to Bochs.
Thx for your advice