[PATCH v5 10/14] gdb: Allow running user-defined commands at GRUB start

[Glenn Washburn]

A new command, run_on_start, for things to do when just 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. A thbreak, temporary hardware breakpoint, is used
because a software breakpoint would be overwritten when the firmware loads
the GRUB image into memory. And it should be temporary in order to have as
many of the limited hardware breakpoints available to the user as possible.

Signed-off-by: Glenn Washburn <development@efficientek.com>
---
 grub-core/gdb_grub.in | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/grub-core/gdb_grub.in b/grub-core/gdb_grub.in
index 18ce6b0eb2..281dfb5927 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,33 @@ 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.
+       thbreak _start
+       commands
+               silent
+
+               runtime_load_module
+
+               if $is_user_command("onstart")
+                       onstart
+               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 +100,7 @@ if ! $runonce
                exec-file kernel.exec
        else
                file kernel.exec
+               run_on_start
                runtime_load_module
        end
 
-- 
2.34.1