[RFC] Dumping load addresses - bootefi qemu gdb remote debugging

Alexander von Gluck IV kallisti5 at unixzen.com
Thu Mar 24 17:27:51 CET 2022

See "[PATCH] efi_loader: Expose relocated address for gdb debugging purposes"

This actually solves the problem by exposing (previously hidden) relocated address.

Now it's a *LOT* easier to debug u-boot loaded EFI binaries using the exposed address:
This is helpful on pretty much every architecture (arm, arm64, riscv64)

(gdb) target extended-remote
Remote debugging using
0x0000000000001000 in ?? ()

(gdb) add-symbol-file u-boot 0xfff66000
add symbol table from file "u-boot" at
	.text_addr = 0xfff66000
(y or n) y
Reading symbols from u-boot...

**ADDRESS from this new log_info:**

(gdb) add-symbol-file objects/haiku/riscv64/debug_1/system/boot/efi/boot_loader_efi 0xbe6c6000
add symbol table from file "objects/haiku/riscv64/debug_1/system/boot/efi/boot_loader_efi" at
	.text_addr = 0xbe6c6000
(y or n) y
Reading symbols from objects/haiku/riscv64/debug_1/system/boot/efi/boot_loader_efi...

(gdb) break platform_start_kernel
Breakpoint 1 at 0xbe6ca87c: file ../src/system/boot/platform/efi/start.cpp, line 178.

(gdb) c

Breakpoint 1, platform_start_kernel () at ../src/system/boot/platform/efi/start.cpp:178
178		smp_init_other_cpus();

^^ success!

Thanks to apalos in IRC for helping to identity where to add this!

 -- Alex

March 24, 2022 10:27 AM, "Bin Meng" <bmeng.cn at gmail.com> wrote:
> +Heinrich Schuchardt
> On Thu, Mar 24, 2022 at 10:51 PM Alex <kallisti5 at unixzen.com> wrote:
>> Good morning!
>> So, some time ago I wrote a short guide on how to debug EFI bootloaders started
>> by u-boot in qemu.
>> https://www.haiku-os.org/blog/kallisti5/2021-01-17_debugging_riscv-64_bootloader_in_qemu
>> At the time it worked, however figuring the elf load addresses from u-boot was extremely
>> difficult and required compiling it with full tracing and taking guesses at
>> various EFI: Entry efi_load_image messages until I found the correct address.
>> Is there an easier way to find the load addresses? If not, a more verbose message
>> on non-debug builds might be extremely useful here.
>> "positioning image at address 0xfe6b0000" or something
>> using the leveraged kernel_addr_r (0x84000000) was not enough.
>> -- Alex

More information about the U-Boot mailing list