The asker is writing a bare-metal OS that enumerates PCIe devices by walking the ECAM (Enhanced Configuration Access Mechanism) memory space. Their function reads the vendor ID at each possible bus/device/function address and saves valid ones. The problem: GDB's x (examine) command shows a different value at the same memory address than what the CPU actually loaded into a register. This is deeply confusing and suggests something fundamental is going on beneath the debugger.

This is a genuinely interesting problem because it sits at the intersection of several tricky x86 concepts:

• Memory-mapped I/O semantics. PCIe configuration space is memory-mapped, meaning reads are not simple RAM fetches — they trigger transactions on the PCIe bus. The hardware at that address can return different values on successive reads, or the value can depend on access width and alignment.
• GDB access width mismatch. When GDB examines memory, it issues its own read via the debug stub (in QEMU's case, the GDB stub built into the emulator). GDB may use a different access width than your code. If your instruction does a 16-bit read (movzx ax, word [addr]) but GDB does a 32-bit or 64-bit read, MMIO devices can respond differently. Some PCIe implementations are strict about access size.
• Caching and memory types. If the ECAM region is not properly marked as uncacheable (UC) in the page tables or MTRRs, the CPU may cache a stale value while GDB's access (going through a different path in the emulator) sees the live device. Conversely, GDB could be reading a cached/stale view while the CPU saw the real device response.
• QEMU's GDB stub behavior. QEMU's internal GDB stub reads guest physical memory directly, bypassing the guest's MMU and caching entirely. So if your OS has set up paging, GDB's x command is reading the raw physical address that your virtual address maps to — but it does so without triggering MMIO side effects the same way a real CPU access would.

The debugging approach should be:

1. Verify the ECAM base address from the MCFG ACPI table — an off-by-one in the bus/device/function calculation shifts all reads.
2. Confirm the ECAM region is mapped as UC in your page tables. Any cacheable mapping of MMIO space will produce bizarre inconsistencies.
3. Check the exact access width in both your assembly and what GDB is issuing. Use x/1hx (halfword) to match a 16-bit vendor ID read.
4. Compare register values immediately after the load (info registers) with the examine output — if the register is correct but x disagrees, it's almost certainly a GDB stub vs. MMIO semantics issue.

A common gotcha: for non-existent PCIe functions, the hardware returns 0xFFFF for the vendor ID. If you're seeing valid-looking values where there should be none, your address calculation is likely hitting a real device's config space repeatedly rather than walking to empty slots.