In GDB (real mode, attached to QEMU), at a specific point under specific conditions stepo and nexti seem to break the breakpoint mechanism

Question

Minimal working example source:

use16
org 0x7c00

jmp 0x0000:@start


@start:
    cli
        mov ax,cs
        mov ds,ax
        mov es,ax
        mov ss,ax
        mov sp,0x7c00
    sti

    mov bp,sp

    call @fails

jmp @start

@fails:
    nop
retn

times 510-($-$$) db 0
dw 0xAA55

The above is assembled to a binary via FASM or NASM and written to the MBR of a VHD (x.vhd). QEMU is started with debugging support enabled: qemu-system-i386.exe -m 512 -boot c -net nic -net user -hda x.vhd -no-acpi -s -S -cpu 486

In Cygwin, with GDB 9.1-1, the following commands are then issued to run GDB and attach to QEMU, identify the architecture, skip over the BIOS code and set a breakpoint at the start of the MBR, loaded at 0x7c00, before continuing:

gdb
target remote localhost:1234
set architecture i8086
stepi 11
break *0x7c00
continue
nexti 10

At this point, the $ip is at the nop line.

@fails:
    nop  ;  <---
retn

Here is where the problem is encountered. Using stepi, a temporary breakpoint is placed on the retn line, execution continues through the nop and breaks where it should. Using stepo or nexti, however, execution does continue without problems, but no breakpoint is reached. GDB just enters an endless wait. If a breakpoint is inserted manually after the nop (on the retn or at jmp @start, the instruction to which the call returns with retn, for example), GDB breaks at that one without issues. Listing all breakpoints at this point produces no new ones, so it seems nexti did not put a temporary breakpoint anywhere (or temporary breakpoints are not listed?).

After a lot of investigation, here are the strange "fixes" for the issue that let nexti automatically just skip over nop and break there as it should: (1) set $ebp = 0x7bfa and then nexti or (2) comment out the line mov bp,sp.

The questions are:

1. Why does nexti seem to break the breakpoint mechanism at that particular location? Perhaps a breakpoint is put between instructions? Or nexti has issues with 16-bit code somehow?
2. Why do the strange "fixes" outlined above work? How can $ebp be at all related to anything if it is not used at any point after the initialization? Does GDB use it internally?

Answer 1

The following gdb command enables remote protocol debugging and results in display of exchange between the gdb and QEMU gdbserver: set debug remote 1. QEMU replies in the exchange look reasonable, the gdb however ends up setting breakpoint at the address 0x5ea7c17, which is wrong. It looks like it interprets 4 bytes at the sp as the return address instead of only 2. 0x7c17 is the actual return address, 0xea and 0x5 are the first two bytes of the boot sector code.