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

[Alexander von Gluck IV]

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.

(gdb) c
Continuing.

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