[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH] gdb: Add more support for debugging on EFI platforms

From: Robbie Harwood
Subject: Re: [RFC PATCH] gdb: Add more support for debugging on EFI platforms
Date: Thu, 16 Mar 2023 17:05:02 -0400

Glenn Washburn <> writes:

> On 3/9/23 23:00, Robbie Harwood wrote:
>> Glenn Washburn <> writes:
>>> If the configure option --enable-efi-debug is given, then enable the
>>> printing early in EFI startup of the command needed to load symbols for
>>> the GRUB EFI kernel. This is needed because EFI firmware determines where
>>> to load the GRUB EFI at runtime, and so the relevant addresses are not
>>> known ahead of time. This is not printed when secure boot is enabled.
>>> The command is a custom command defined in the gdb_grub GDB script. So
>>> GDB should be started with the script as an argument to the -x option or
>>> sourced into an active GDB session before running the outputted command.
>>> Also a command named "gdbinfo" is enabled which allows the user to print
>>> the gdb command string on-demand, which can be valuable as the printing
>>> early in EFI startup is quickly replaced by other text. So if using a
>>> physical screen it may appear too briefly to be registered.
>>> Co-developed-by: Peter Jones <>
>>> Signed-off-by: Glenn Washburn <>
>>> ---
>>> This is patch 9 from the v6 "GDB script fixes and improvements" series, with
>>> one modification. Now the gdbinfo command will print the gdb load command
>>> even when the configure option is not enabled (though still not when 
>>> lockdown
>>> is enabled).
>>> Robbie had 2 concerns with the last patch.
>>>   1. Does this need to be configurable?
>>>     * I responded that this was requested by Daniel because of concerns 
>>> about
>>>       it breaking silent boot and it seemed reasonable to me, but that I 
>>> don't
>>>       have a strong opinion. I've left it configurable until Dnaiel weighs 
>>> in.
>> Yeah, I think these concerns are valid.  The version in the rhboot
>> tree gates printing on an env var.  Right now, it seems to me that:
>> - we want it to be default-off because silent boot
> I understand you to be talking about a default-off at runtime, not
> built time. Right now there is a configure option which defaults to
> off, is this acceptable?

Indeed, I'm talking about runtime configurability.  Build-time
configurability means it's either always on (bad) or we have to rebuild
in order to debug (annoying, interacts poorly with scureboot).

>> - we want to have the ability to reenable without rebuilding because
>>    secureboot, convenience, etc.
> This would be great, but how do you propose that this would work? This 
> patch will print very early in EFI init. We can't use GRUB variables. We 
> probably could use EFI variables, but this needs to be well defined (and 
> not by me, since I don't have this requirement). I'm not sure if the 
> GRUB env block is available at this point, but that might be an option.
> Can you point me to RH's patch you've referred to? Does it meet this 
> requirement, and if so how?

I thought you were basing your work off it, given the "Co-developed-by"
and your review on v1:

(v2 was and
the versions we're shipping are

As you say, the grub env block isn't available (module loading happens
before filesystems).  We have an additional patch that allows the use of
an EFI variable for setting grubenv:
which lets one do e.g.

    grub2-editenv ./grubenv set debug=gdb,modules,dl
    { printf '\x07\x00\x00\x00' ; cat ./grubenv ; } > 
    cp GRUB_ENV-91376aff-cba6-42be-949d-06fde81128e8 /sys/firmware/efi/efivars/

and then have configuration for the next boot.  Javier informally
proposed this to the list a few years ago for ZFS-related things: but
I don't think it was ever followed up on, possibly because ZFS is not
one of our use cases :)

I'm happy to formally propose it, or feel free to include/adapt it if
it's helpful to you, etc..

Be well,

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]