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 <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>

diff --git a/grub-core/gdb_grub.in b/grub-core/gdb_grub.in
index 18ce6b0eb2d43b3d08c441c6f2166d40d06ff443..8e89bbf3683b06a2444f7e78dfaec1e6f305f78a 100644 (file)
--- 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