From: Glenn Washburn Date: Mon, 27 Feb 2023 21:15:36 +0000 (-0600) Subject: gdb: Allow running user-defined commands at GRUB start X-Git-Tag: grub-2.12-rc1~108 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=4ea9e6e3a6f64c828a7e370667c18a87bfd8c8e0;p=thirdparty%2Fgrub.git gdb: Allow running user-defined commands at GRUB start A new command, run_on_start, for things to do before GRUB starts executing. Currently, this is setting up the loading of module symbols as they are loaded and allowing user-defined script to be run if a command named "onstart" exists. On some platforms, notably x86, software breakpoints set in GDB before the GRUB image is loaded will be cleared when the image is loaded. This is because the breakpoints work by overwriting the memory of the break- point location with a special instruction which when hit will cause the debugger to stop execution. Just before execution is resumed by the debugger, the original instruction bytes are put back. When a breakpoint is set before the GRUB image is loaded, the special debugger instruction will be written to memory and when the GRUB image is loaded by the firmware, which has no knowledge of the debugger, the debugger instruction is overwritten. To the GDB user, GDB will show the breakpoint as set, but it will never be hit. Furthermore, GDB now becomes confused, such that even deleting and re-setting the breakpoint after the GRUB image is loaded will not allow for a working breakpoint. To work around this, in run_on_start, first a watchpoint is set on _start, which will be triggered when the firmware starts loading the GRUB image. When the _start watchpoint is hit, the current breakpoints are saved to a file and then deleted by GDB before they can be overwritten by the firmware and confuse GDB. Then a temporary software breakpoint is set on _start, which will get triggered when the firmware hands off to GRUB to execute. In that breakpoint load the previously saved and deleted breakpoints now that there is no worry of them getting overwritten by the firmware. This is needed for runtime_load_module to work when it is run before the GRUB image is loaded. Note that watchpoints are generally types of hardware breakpoints on x86, so its deleted as soon as it gets triggered so that a minimal set of hardware breakpoints are used, allowing more for the user. Signed-off-by: Glenn Washburn Reviewed-by: Daniel Kiper --- diff --git a/grub-core/gdb_grub.in b/grub-core/gdb_grub.in index 18ce6b0eb..8e89bbf36 100644 --- a/grub-core/gdb_grub.in +++ b/grub-core/gdb_grub.in @@ -15,6 +15,8 @@ source gdb_helper.py define dynamic_load_symbols dynamic_load_kernel_exec_symbols $arg0 + run_on_start + # We may have been very late to loading the kernel.exec symbols and # and modules may already be loaded. So load symbols for any already # loaded. @@ -54,6 +56,54 @@ document runtime_load_module Load module symbols at runtime as they are loaded. end +define run_on_start + # TODO: Add check to see if _start symbol is defined, if not, then + # the symbols have not yet been loaded and this command will not work. + watch *_start + set $break_efi_start_bpnum = $bpnum + commands + silent + delete $break_efi_start_bpnum + + # Save the breakpoints here before the GRUB image is loaded + # into memory, then delete them. Later they will be reloaded + # once the GRUB image has been loaded. This avoids the issue + # where the loading of the GRUB image overwrites the software + # breakpoints, thus confusing GDB and effectively clearing + # those breakpoints. + save breakpoints .early-breakpoints.gdb + delete breakpoints + + tbreak _start + commands + silent + + # Reload the breakpoints now that the GRUB image has + # finished being loaded into memory. + source .early-breakpoints.gdb + + runtime_load_module + + if $is_user_command("onstart") + onstart + end + continue + end + continue + end +end +document run_on_start + On some targets, such as x86_64-efi, even if you know where the + firmware will load the GRUB image, you can not simply set a break + point before the image is loaded because loading the image + overwrites the break point in memory. So setup a hardware watch + point, which does not have that problem, and if that gets triggered, + then reset the break point. If a user-defined command named + "onstart" exists it will be run after the start is hit. + NOTE: This assumes symbols have already been correctly loaded for + the EFI application. +end + ### set confirm off @@ -71,6 +121,7 @@ if ! $runonce exec-file kernel.exec else file kernel.exec + run_on_start runtime_load_module end