Debug GRUB2 EFI image running on QEMU

The accepted answer worked like magic for me.

BTW, I use the following lower-level executable to build the EFI, same as for a full debian qemu image (the command creates a smaller EFI and can be run from any directory.)

MODULES="search iso9660 configfile normal memdisk tar part_msdos part_gpt fat"
$GRUB_PATH/grub-mkimage -O x86_64-efi -d $GRUB_PATH/grub-core -p "" -o ./grub.efi $MODULES

I still have to start the gdb session in the same source directory as kernel.exec because the source file paths are relative to that directory.

There are no debug symbols included in your bootIA32.efi image. The gdb_grub script attempts to do this, but since it was designed for BIOS (not UEFI), and appears to basically be included and generated mainly by accident, this does not really function anymore - since the EFI version of GRUB is dynamically to an address decided at runtime.

Now, with a bit of trickery (and an OVMF_CODE.fd built with -D DEBUG_ON_SERIAL_PORT), I can see that as long as I don't run any other commands before entering GRUB, I always see:

Loading driver at 0x0003DDE9000 EntryPoint=0x0003DDE9400

So with a horrible hack to gdb_grub, changing the line near the end:

file kernel.exec

to

add-symbol-file kernel.exec 0x0003DDE9400

I end up with a situation instead of

add symbol table from file "kernel.exec" at
.text_addr = 0x3dde9400
0x0000fff0 in ?? ()
Breakpoint 1 at 0x3ddedddb: file kern/dl.c, line 53.
(gdb)

After this point. And if I then continue, the module symbol loading now works as the script intended:

(gdb) cont
Continuing.
add symbol table from file "memdisk.module" at
    .text_addr = 0x3bf75cb0
    .rodata.str1.1_addr = 0x3bf75e77
    .data_addr = 0x3bf75ee0
    .module_license_addr = 0x3bf75f00
    .bss_addr = 0x3bf75f10
add symbol table from file "archelp.module" at
    .text_addr = 0x3b885ef0
    .rodata.str1.1_addr = 0x3b8864d6
    .module_license_addr = 0x3b88653c

Not exactly production-ready, but workable.