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@gmail.com wrote:

+Heinrich Schuchardt

On Thu, Mar 24, 2022 at 10:51 PM Alex kallisti5@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_bootlo...

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