How to step over interrupt calls when debugging a bootloader/bios with gdb and QEMU?

Question

For educational purposes, I have adapted this bootloader from mikeos.berlios.de/write-your-own-os.html rewriting it to specifically load at address 0x7c00.

The final code is this:

[BITS 16]           ; Tells nasm to build 16 bits code
[ORG 0x7C00]        ; The address the code will start

start: 
    mov ax, 0       ; Reserves 4Kbytes after the bootloader
    add ax, 288 ; (4096 + 512)/ 16 bytes per paragraph 
    mov ss, ax 
    mov sp, 4096 
mov ax, 0   ; Sets the data segment 
    mov ds, ax 
    mov si, texto   ; Sets the text position 
    call imprime    ; Calls the printing routine
jmp $       ; Infinite loop 
    texto db 'It works! :-D', 0 
imprime:            ; Prints the text on screen
    mov ah, 0Eh     ; int 10h - printing function 
.repeat: 
    lodsb           ; Grabs one char 
    cmp al, 0 
    je .done        ; If char is zero, ends 
    int 10h         ; Else prints char 
jmp .repeat 
.done: 
ret 
times 510-($-$$) db 0 ; Fills the remaining boot sector with 0s 
dw 0xAA55             ; Standard boot signature

I can step through the program and see the registers changing, along with the instruction being executed, stepping with gdb (si) and inspecting with QEMU monitor (info registers, x /i $eip, etc).

After I get into int 10h (the BIOS printing routine), things get a little strange. If I step 500 instructions at once, I can see the character "I" (the first of char of my text string) printed on the screen. So I restarted again and stepped 400 steps (si 400) and then I did one step at a time to see in which exact step "I" got printed. It never happened. I actually stepped 200 steps one by one and nothing happened. As soon as I stepped 100 steps at once (si 100) I got "I" printed on the screen again.

So, I wonder if there is a timing issue (some system interrupt gets in the way as I do a step by step debug). What else could this be?

Anyway, is there a way of skipping the whole BIOS interrupt and other functions and just go back and keep stepping the bootloader code? As suggested by Peter Quiring in the comments, I tried using next. This did not work.

(gdb) next 
Cannot find bounds of current function

So I tried nexti and it just behaves as si.

Thanks!

Answer 1

I've automated your procedure with a Python script that:

• calculates the length of the current instruction
• sets a temporary breakpoint on the next instruction
• continues

This will also work for any other instruction, but I don't see many other use cases for it, since nexti already jumps over call.

class NextInstructionAddress(gdb.Command):
    """
Run until Next Instruction address.

Usage: nia

Put a temporary breakpoint at the address of the next instruction, and continue.

Useful to step over int interrupts.

See also: http://stackoverflow.com/questions/24491516/how-to-step-over-interrupt-calls-when-debugging-a-bootloader-bios-with-gdb-and-q
"""
    def __init__(self):
        super().__init__(
            'nia',
            gdb.COMMAND_BREAKPOINTS,
            gdb.COMPLETE_NONE,
            False
        )
    def invoke(self, arg, from_tty):
        frame = gdb.selected_frame()
        arch = frame.architecture()
        pc = gdb.selected_frame().pc()
        length = arch.disassemble(pc)[0]['length']
        gdb.Breakpoint('*' + str(pc + length), temporary = True)
        gdb.execute('continue')
NextInstructionAddress()

Just drop that into ~/.gdbinit.py and add source ~/.gdbinit.py to your ~/.gdbinit file.

Tested on GDB 7.7.1, Ubuntu 14.04.

Answer 2

This is actually a work around that fits my purposes. What I did was setting breakpoints so I can use "continue" on gdb along with "si" and follow the message being printed on the screen, one character at a time. Here are the steps.

In the first run, I do step my bootloader, so I can actually check the memory positions where the instructions are stored.

Linux shell:

# qemu-system-i386 -fda loader.img -boot a -s -S -monitor stdio
QEMU 1.5.0 monitor - type 'help' for more information
(qemu) 

Other Linux shell (some lines have been supressed [...]):

# gdb
GNU gdb (GDB) 7.6.1-ubuntu
[...]
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
0x0000fff0 in ?? ()
(gdb) set architecture i8086
[...]
(gdb) br *0x7c00
Ponto de parada 1 at 0x7c00
(gdb) c
Continuando.
Breakpoint 1, 0x00007c00 in ?? ()
(gdb) si
0x00007c03 in ?? ()

In the terminal I am running QEMU monitor, I find the address of the instructions executing this command after every si on gdb:

(qemu) x /i $eip
0x00007c03:  add    $0x120,%ax

For those new to QEMU, x display the contents of a register, /i translates it into an instruction and $eip is the instruction point register. By repeating these steps, I find out the addresses for the lodsb and int 10h instructions:

0x00007c29:  lods   %ds:(%si),%al 
0x00007c2e:  int    $0x10 

So, on gdb I just set the breakpoints for these aditional positions:

(gdb) br *0x7c29
Ponto de parada 2 at 0x7c29
(gdb) br *0x7c2e
Ponto de parada 3 at 0x7c2e

Now I can use a combination of "continue" (c) and stepi (si) on gdb and skip through the whole BIOS stuff.

There is probably better ways to do this. However, for my pedagogical purposes, this method works quite well.

Answer 3

Actually, QEMU has already considered this situation. QEMU gdbstub internally has two flags: NOIRQ and NOTIMER. These two flags will prevent irqs been injected to guest and pause timer clock emulation in single step mode. You can query the capbility of your qemu by:

(gdb) maintenance packet qqemu.sstepbits
sending: "qqemu.sstepbits"
received: "ENABLE=1,NOIRQ=2,NOTIMER=4"

For KVM, you probably need linux kernel v5.12+ for your host to support NOIRQ, which implements ioctl KVM_CAP_SET_GUEST_DEBUG2.

But plase note, NOIRQ only prevents irqs, execptions/traps are still been injected.