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

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

[Alexander von Gluck IV]

* If users want to debug EFI applications via qemu + GDB, they
  need to know the relocated address of the application to
  align their symbols to in GDB via add-symbol-file.
* This exposes where EFI applications are relocated to enable
  debugging EFI applications via qemu + gdb
* Usage is generally determining the address, then
  add-symbol-file (efi loader) (address)
* The address can change, but is generally consistent with
  the same qemu version and u-boot binary. (allowing you to
  boot once, find the address, then reboot with qemu -s -S
---
 lib/efi_loader/efi_image_loader.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lib/efi_loader/efi_image_loader.c b/lib/efi_loader/efi_image_loader.c
index 773bd0677c..2b8c1ef464 100644
--- a/lib/efi_loader/efi_image_loader.c
+++ b/lib/efi_loader/efi_image_loader.c
@@ -906,6 +906,8 @@ efi_status_t efi_load_pe(struct efi_loaded_image_obj *handle,
 			ret = EFI_OUT_OF_RESOURCES;
 			goto err;
 		}
+		log_info("64-bit EFI image loaded at relocated address %p\n", efi_reloc);
+
 		handle->entry = efi_reloc + opt->AddressOfEntryPoint;
 		rel_size = opt->DataDirectory[rel_idx].Size;
 		rel = efi_reloc + opt->DataDirectory[rel_idx].VirtualAddress;
@@ -922,6 +924,8 @@ efi_status_t efi_load_pe(struct efi_loaded_image_obj *handle,
 			ret = EFI_OUT_OF_RESOURCES;
 			goto err;
 		}
+		log_info("32-bit EFI image loaded at relocated address %p\n", efi_reloc);
+
 		handle->entry = efi_reloc + opt->AddressOfEntryPoint;
 		rel_size = opt->DataDirectory[rel_idx].Size;
 		rel = efi_reloc + opt->DataDirectory[rel_idx].VirtualAddress;
-- 
2.35.1

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

[Heinrich Schuchardt]

On 3/24/22 17:22, Alexander von Gluck IV wrote:
> * If users want to debug EFI applications via qemu + GDB, they
>    need to know the relocated address of the application to
>    align their symbols to in GDB via add-symbol-file.
> * This exposes where EFI applications are relocated to enable
>    debugging EFI applications via qemu + gdb
> * Usage is generally determining the address, then
>    add-symbol-file (efi loader) (address)
> * The address can change, but is generally consistent with
>    the same qemu version and u-boot binary. (allowing you to
>    boot once, find the address, then reboot with qemu -s -S
> ---
>   lib/efi_loader/efi_image_loader.c | 4 ++++
>   1 file changed, 4 insertions(+)
>
> diff --git a/lib/efi_loader/efi_image_loader.c b/lib/efi_loader/efi_image_loader.c
> index 773bd0677c..2b8c1ef464 100644
> --- a/lib/efi_loader/efi_image_loader.c
> +++ b/lib/efi_loader/efi_image_loader.c
> @@ -906,6 +906,8 @@ efi_status_t efi_load_pe(struct efi_loaded_image_obj *handle,
>   			ret = EFI_OUT_OF_RESOURCES;
>   			goto err;
>   		}
> +		log_info("64-bit EFI image loaded at relocated address %p\n", efi_reloc);
> +
>   		handle->entry = efi_reloc + opt->AddressOfEntryPoint;
>   		rel_size = opt->DataDirectory[rel_idx].Size;
>   		rel = efi_reloc + opt->DataDirectory[rel_idx].VirtualAddress;
> @@ -922,6 +924,8 @@ efi_status_t efi_load_pe(struct efi_loaded_image_obj *handle,
>   			ret = EFI_OUT_OF_RESOURCES;
>   			goto err;
>   		}
> +		log_info("32-bit EFI image loaded at relocated address %p\n", efi_reloc);
> +
>   		handle->entry = efi_reloc + opt->AddressOfEntryPoint;
>   		rel_size = opt->DataDirectory[rel_idx].Size;
>   		rel = efi_reloc + opt->DataDirectory[rel_idx].VirtualAddress;

Do we really always need this output for every invokation of LoadImage()?

Writing test messages during the runtime of a menu driven program like
the UEFI SCT can be very disturbing.

Isn't it sufficient to show this output for binaries directly launched
by U-Boot?

Best regards

Heinrich

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

[Alexander von Gluck IV]

March 24, 2022 12:06 PM, "Heinrich Schuchardt" <xypron.glpk@gmx.de> wrote:
> On 3/24/22 17:22, Alexander von Gluck IV wrote:
> Do we really always need this output for every invokation of LoadImage()?
> 
> Writing test messages during the runtime of a menu driven program like
> the UEFI SCT can be very disturbing.
> 
> Isn't it sufficient to show this output for binaries directly launched
> by U-Boot?

Ideally this would be exposed strictly for the binaries directly launched,
however the bare relocated address isn't exposed outside of the brief
usage by LoadImage.

I figured that adding a required pointer arg to expose the relocated address
might be overkill.

using log_debug over log_info was brought up as a good change, but that
still suffers the same potential impact.

Maybe adding reloc_addr storage to efi_loaded_image_obj would be cleaner?
(then digging it up during the efi launch for a quick log_info?)

 -- Alex

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

[Alex]

March 24, 2022 1:25 PM, "Alexander von Gluck IV" <kallisti5@unixzen.com> wrote:
> March 24, 2022 12:06 PM, "Heinrich Schuchardt" <xypron.glpk@gmx.de> wrote:
> 
>> On 3/24/22 17:22, Alexander von Gluck IV wrote:
>> Do we really always need this output for every invokation of LoadImage()?
>> 
>> Writing test messages during the runtime of a menu driven program like
>> the UEFI SCT can be very disturbing.
>> 
>> Isn't it sufficient to show this output for binaries directly launched
>> by U-Boot?
> 
> Ideally this would be exposed strictly for the binaries directly launched,
> however the bare relocated address isn't exposed outside of the brief
> usage by LoadImage.
> 
> I figured that adding a required pointer arg to expose the relocated address
> might be overkill.
> 
> using log_debug over log_info was brought up as a good change, but that
> still suffers the same potential impact.
> 
> Maybe adding reloc_addr storage to efi_loaded_image_obj would be cleaner?
> (then digging it up during the efi launch for a quick log_info?)

"PATCH] efi_loader (v2): Expose relocated address for gdb debugging purposes"
has been submitted.  Instead of printing the relocated address out immediately,
v2 stores it in the efi_loaded_image_obj and references it later during the 
initial EFI boot.

The output of v2 can be seen below.


54 bytes read in 0 ms
uEnv.txt says to look for efi bootloader named EFI/BOOT/BOOTRISCV64.EFI on virtio 0!
Found EFI/BOOT/BOOTRISCV64.EFI on virtio 0!
Loading bootloader...
800283 bytes read in 1 ms (763.2 MiB/s)
Using internal DTB...
Launching EFI loader...
Scanning disk virtio-blk#8...
Found 3 disks
** Unable to read file ubootefi.var **
Failed to load EFI variables
Booting /EFI\BOOT\BOOTRISCV64.EFI
EFI image relocated to 0xbe68e000