[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 127.0.0.1:1234
Remote debugging using 127.0.0.1:1234
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.
Breakpoint 1, platform_start_kernel () at ../src/system/boot/platform/efi/start.cpp:178
Thanks to apalos in IRC for helping to identity where to add this!
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.
>> 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