grub-devel
[Top][All Lists]
Advanced

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

[PATCH 0/8] GDB script fixes and improvements


From: Glenn Washburn
Subject: [PATCH 0/8] GDB script fixes and improvements
Date: Sun, 13 Feb 2022 21:42:37 -0600

This is a collection of fixes and improvements mostly to the GDB script,
gdb_grub. I don't think the first 4 need commnt.

A major benefit added in patch #5 is the ability to properly load symbols on
EFI targets given the load address for the text and data segments. This is
written as a shell script in the GDB script primarily because I'm not
familiar with the Python API. I think it would probably be better written in
Python, though. Daniel what do you think about using Python in the GDB script?
First of all, I get the impression that this script isn't used much (but I'd
like to know if I'm wrong about that), so I suspect changes won't affect many
people one way or the other. And second, I think its reasonable to assume
these days that people's GDB is compiled with Python support.

Patch #6 has code stolen from the patch by Peter Jones[1]. I've added a
Co-developed-by tag. Let me know if there's something different I should do.
I've removed the printing of lines for each module as this is unnecessary if
the kernel.exec symbols have been loaded correctly (see load_all_modules in
gdb_grub). Also, I've made the printed message for loading kernel.exec
symbols only happen if enabled by setting PRINT_GDB_SYM_LOAD_CMD to a non-
zero value in config.h.in.

Ultimately, I think a better solution is to check the EFI variables for a
certain value and enable the print using that. This way support would always
be compiled in and can still be enabled very early in the GRUB boot process.
However, I'm not sure what that variable should be, or if we should just
create our own variable. Someone more experienced in EFI than I could help
with that or say that using an EFI var would be unadvisable.

Testing on QEMU with OVMF firmware, shows that GRUB will be loaded to the
same address consistently so long as the binary hasn't changed. This is nice
because by the time you get the message with the right parameters needed to
load the symbols you may have already passed by code you wanted to break on.
So you can use the same parameters to load the symbols before GRUB executes
and set break points as early as you want in GRUB code. I'm not sure if this
is true of real hardware, but I suspect it is. If this is so, then Daniel's
idea of making this a command may make sense as well, so that GRUB doesn't
need to be recompiled in "debug mode" to get this address. Of course, if
GRUB is failing before module initialization, the module won't work.

Patch #7 adds a check if the build was for an EFI platform and runs the
dynamic code at startup if so. As noted in the commit message, without this
the user must remember to first remove the symbols loaded at the statically
positioned offset. Otherwise, symbols will be multiply defined and GDB uses
the first ones defined by default. It was suggested by Vladimir that targets
with platform as EFI were all the dynamic ones[2], but 10+ years later this
may have changed. Other target tests can be added as needed for ones that are
dynamic but are not EFI.

Patch #8 This is a work around for a strange issue where GDB is stopping
before the stack frame has been setup when breaking on grub_dl_add(). But
GDB thinks that the stack frame has been setup. I'm not sure what is causing
this (not using -fomit-frame-pointer and don't see any obvious culprits in
other GCC compile options). I also don't particularly like this solution,
but its the best one I've found. I originally was going up a frame in
grub_dl_add() and getting the mod variable there, but that assumes knowledge
of the caller. I'd like to set a break point on the instruction that I'd get
to by issuing a "step" in GDB after the break on grub_dl_add, but I don't see
a way to do that. Another option is to set an unused label in grub_dl_add()
and do a tbreak on the label, but I was wanting to avoid code changes.
Maybe this is acceptable though.

Glenn

[1] https://lists.gnu.org/archive/html/grub-devel/2021-11/msg00008.html
[2] https://lists.gnu.org/archive/html/grub-devel/2011-11/msg00069.html

Glenn Washburn (8):
  gdb: Move runtime module loading into runtime_load_module
  gdb: If no modules have been loaded, do not try to load module symbols
  gdb: Do not lazy load module symbols
  gdb: Prevent wrapping when writing to .segments.tmp
  gdb: Add functions to make loading from dynamically positioned targets
    easier
  gdb: If enabled, print line used to load EFI kernel symbols when using
    gdb_grub script
  gdb: Conditionally run GDB script logic for dynamically or statically
    positioned GRUB
  gdb: Get correct mod variable value

 config.h.in               |   3 ++
 grub-core/gdb_grub.in     | 109 ++++++++++++++++++++++++++++++++++----
 grub-core/gmodule.pl.in   |   2 +-
 grub-core/kern/efi/efi.c  |   4 +-
 grub-core/kern/efi/init.c |  25 ++++++++-
 include/grub/efi/efi.h    |   2 +-
 6 files changed, 131 insertions(+), 14 deletions(-)

-- 
2.27.0




reply via email to

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