Daniel, Is this still in the to be reviewed queue? Despite how long its been, I believe this patch series still applies cleanly to master.
Glenn On Mon, 23 Sep 2024 01:04:54 -0500 Glenn Washburn <developm...@efficientek.com> wrote: > Update v2: > * Rebase onto current master. This really did not change the contents of > the patch though > > This patch series (for me) was motivated by the "gdb: Add more support for > debugging on EFI platforms" patch series, which allowed printing in early > EFI init of the GDB command for properly loading symbols. That approach of > having the functionality be included at compile time was ultimately > rejected. During the discussion of that series, Robbie suggested[1] using > patches by Peter and in the Redhat downstream repo which uses an EFI > variable to store a GRUB env block. Using this, a user could store a > variable in the env block stored in the EFI variable and then have GRUB > load that env block in early init as a way to enable the printing of the > GDB command. > > I've taken the original patches by Peter, made more suitable for including > in GRUB, fixed some bugs, and added a minor feature. The first patch, adds > env block loading in early EFI init from the GRUB_ENV EFI variable. The > second patch is included to provide tools for GRUB to set this EFI env > block itself, as opposed to needing to use the method suggested by > Robbie[1], which requires GNU/Linux and the user-space grub2-editenv > utility. Of course, if GRUB is crashing before one can run the > efi-export-env command, then other ways of creating and setting the EFI > envblk variable are necessary. The third patch adds a test which checks the > usability of the commands and the early init loading. And the last patch, > whichvmotivated this series, prints the GDB command string if the GRUB > variable named "enable_earlyinit_gdbinfo" is present and is set to "1", after > the env block is loaded from the GRUB_ENV EFI variable. We might want a > different name for the GRUB variable, I don't really have a preference. > > Glenn > > [1] https://mail.gnu.org/archive/html/grub-devel/2023-03/msg00072.html > > Glenn Washburn (2): > tests: Add efienv_test for testing efi-export-env and efi-load-env > efi: Print GDB command for loading symbols if variable exists > > Peter Jones (2): > efi: Load env block from GRUB_ENV EFI variable in early init > efi: Add efi-export-env and efi-load-env commands > > Makefile.util.def | 6 ++ > docs/grub.texi | 24 +++++ > grub-core/Makefile.core.def | 7 ++ > grub-core/commands/efi/env.c | 182 +++++++++++++++++++++++++++++++++++ > grub-core/kern/efi/efi.c | 3 + > grub-core/kern/efi/init.c | 37 +++++++ > grub-core/lib/envblk.c | 43 +++++++++ > include/grub/efi/efi.h | 5 + > include/grub/lib/envblk.h | 3 + > tests/efienv_test.in | 57 +++++++++++ > 10 files changed, 367 insertions(+) > create mode 100644 grub-core/commands/efi/env.c > create mode 100644 tests/efienv_test.in > > Range-diff against v1: > 1: 15a9c7112eae ! 1: d2ad090d7486 efi: Load env block from GRUB_ENV EFI > variable in early init > @@ grub-core/kern/efi/init.c > #ifdef GRUB_STACK_PROTECTOR > > static grub_efi_char16_t stack_chk_fail_msg[] = > -@@ grub-core/kern/efi/init.c: stack_protector_init (void) > +@@ grub-core/kern/efi/init.c: grub_stack_protector_init (void) > > grub_addr_t grub_modbase; > > 2: d000cdbd0468 = 2: 456f4245ef76 efi: Add efi-export-env and efi-load-env > commands > 3: 3966eba4a32b = 3: 04072bccc2c7 tests: Add efienv_test for testing > efi-export-env and efi-load-env > 4: b65e7a8bac40 = 4: a23667d25f40 efi: Print GDB command for loading > symbols if variable exists _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
