2

I was using qemu and gdb to follow the booting process of a computer. I made qemu to pause at the first instruction of bios. Unsurprisingly, qemu paused at 0xfff0. But when I tried to see the assembly codes by typing in layout asm, it didn't show assembly correctly. All of the assembly instruction displayed in asm window were add commands. For example, the first instruction should be a jump, but it displayed as add %al,(%eax).

enter image description here

Michael Petch
  • 46,082
  • 8
  • 107
  • 198
Bicheng
  • 687
  • 8
  • 20
  • 2
    `add %al, (%eax)` has opcode `00 00`, so you are looking at a bunch of zero bytes, not actual code. Note that the BIOS reboot address is F000:FFF0, and the debugger probably doesn't know you want to be looking at segment F000. – Nate Eldredge Sep 02 '20 at 21:46
  • @NateEldredge I don't think I am looking at a bunch of zero bytes. Because when I type in `stepi` command, it does jump to another address, which means the first `add` instruction is actually a `jump` not `add`. – Bicheng Sep 03 '20 at 00:34
  • 2
    Then at least, the region of memory you are disassembling does not correspond to the code that is actually being executed. This seems consistent with the answer linked by Michael Petch: it sounds like gdb doesn't know about the segment registers, and chooses the address to disassemble based on IP alone. So you are executing code at F000:FFF0, but gdb is disassembling what's at 0000:FFF0 which happens to be all zero bytes. – Nate Eldredge Sep 03 '20 at 00:41
  • @NateEldredge But I have added `set arch i8086` in gdbinit. Why it doesn't work? Actually the course material suggested this solution to work around this problem. – Bicheng Sep 03 '20 at 01:51
  • Have you read the answer which Michael Petch linked above? It explains in great detail how gdb's support for 8086 is very poor, even with `set arch i8086`. – Nate Eldredge Sep 03 '20 at 02:03
  • 2
    GDB over the past few years has basically made `set arch i8086` useless by itself for actually debugging 16-bit real mode code. The book/tutorial/material you are using predates these changes. You would either have to do the hack (or something like it) suggested in the duplicate question I suggested or build and old version of GDB from source. But the reality is the memory you are viewing in the debugger is not the memory that the code is executing from. – Michael Petch Sep 03 '20 at 04:51
  • 3
    The only place in memory that GDB can effectively debug is when the segment registers are zero.When debugging the BIOS you start with a non zero segment like 0xf000. GDB has never properly supported this.If you want to step through a BIOS might I consider using BOCHs which actually has a debugger that understands segment:offset addressing. – Michael Petch Sep 03 '20 at 05:09

0 Answers0