sd-boot,sd-stub: also print version after the address

The kernel, systemd, and many other things print their version during boot.
sd-boot and sd-stub are also important, so let's print the version if EFI_DEBUG.
(If !EFI_DEBUG, continue to be quiet.)

When updating the docs, I saw that that the text in HACKING.md was out of date.
Instead of trying to update the instructions there, make it shorter and refer
the reader to tools/debug-sd-boot.sh for details.

diff --git a/docs/HACKING.md b/docs/HACKING.md
index 0aa92333452747031748c4f99e0a0fb331ce15dc..6680ebc91f69b495221a2da9bd23886fb614767b 100644 (file)
--- a/docs/HACKING.md
+++ b/docs/HACKING.md
@@ -299,24 +299,17 @@ container to figure out the PID and enter it when asked and VSCode will attach t
 
 ## Debugging systemd-boot
 
-During boot, systemd-boot and the stub loader will output a message like `systemd-boot@0x0A,0x0B`,
-providing the location of the text and data sections. These location can then be used to attach
-to a QEMU session (provided it was run with `-s`) with these gdb commands:
-
-```
-    (gdb) file build/src/boot/efi/systemd-bootx64.efi
-    (gdb) add-symbol-file build/src/boot/efi/systemd_boot.so 0x0A -s .data 0x0B
-    (gdb) set architecture i386:x86-64
-    (gdb) target remote :1234
-```
-
-This process can be automated by using the `debug-sd-boot.sh` script in the tools folder. If run
-without arguments it will provide usage information.
-
-If the debugger is too slow to attach to examine an early boot code passage, we can uncomment the
-call to `debug_break()` inside of `efi_main()`. As soon as the debugger has control we can then run
-`set variable wait = 0` or `return` to continue. Once the debugger has attached, setting breakpoints
-will work like usual.
+During boot, systemd-boot and the stub loader will output messages like
+`systemd-boot@0x0A` and `systemd-stub@0x0B`, providing the base of the loaded
+code. This location can then be used to attach to a QEMU session (provided it
+was run with `-s`). See `debug-sd-boot.sh` script in the tools folder which
+automates this processes.
+
+If the debugger is too slow to attach to examine an early boot code passage,
+the call to `DEFINE_EFI_MAIN_FUNCTION()` can be modified to enable waiting. As
+soon as the debugger has control, we can then run `set variable wait = 0` or
+`return` to continue. Once the debugger has attached, setting breakpoints will
+work like usual.
 
 To debug systemd-boot in an IDE such as VSCode we can use a launch configuration like this:
 ```json

diff --git a/src/boot/efi/util.c b/src/boot/efi/util.c
index b339021fe9756fe07ee0da49782cfc980ad1bdb4..c5f17424664adb67b1111e54f955026b81c75c94 100644 (file)
--- a/src/boot/efi/util.c
+++ b/src/boot/efi/util.c
@@ -4,6 +4,7 @@
 #include "proto/simple-text-io.h"
 #include "ticks.h"
 #include "util.h"
+#include "version.h"
 
 EFI_STATUS parse_boolean(const char *v, bool *b) {
         assert(b);
@@ -543,10 +544,9 @@ uint64_t get_os_indications_supported(void) {
         return osind;
 }
 
-#ifdef EFI_DEBUG
-extern uint8_t __ImageBase;
 __attribute__((noinline)) void notify_debugger(const char *identity, volatile bool wait) {
-        printf("%s@%p\n", identity, &__ImageBase);
+#ifdef EFI_DEBUG
+        printf("%s@%p %s\n", identity, &__ImageBase, GIT_VERSION);
         if (wait)
                 printf("Waiting for debugger to attach...\n");
 
@@ -554,15 +554,15 @@ __attribute__((noinline)) void notify_debugger(const char *identity, volatile bo
          * has attached to us. Just "set variable wait = 0" or "return" to continue. */
         while (wait)
                 /* Prefer asm based stalling so that gdb has a source location to present. */
-#if defined(__i386__) || defined(__x86_64__)
+#  if defined(__i386__) || defined(__x86_64__)
                 asm volatile("pause");
-#elif defined(__aarch64__)
+#  elif defined(__aarch64__)
                 asm volatile("wfi");
-#else
+#  else
                 BS->Stall(5000);
+#  endif
 #endif
 }
-#endif
 
 #ifdef EFI_DEBUG
 void hexdump(const char16_t *prefix, const void *data, size_t size) {

diff --git a/src/boot/efi/util.h b/src/boot/efi/util.h
index bb917faf5541c685973780064b1e95f908948e55..929f3bca8c839677c83c6ed5e089b7b9d6b7b1d9 100644 (file)
--- a/src/boot/efi/util.h
+++ b/src/boot/efi/util.h
@@ -6,6 +6,9 @@
 #include "proto/file-io.h"
 #include "string-util-fundamental.h"
 
+/* This is provided by linker script. */
+extern uint8_t __ImageBase;
+
 static inline void free(void *p) {
         if (!p)
                 return;
@@ -160,13 +163,12 @@ static inline void *PHYSICAL_ADDRESS_TO_POINTER(EFI_PHYSICAL_ADDRESS addr) {
 
 uint64_t get_os_indications_supported(void);
 
-#ifdef EFI_DEBUG
-/* Report the relocated position of text and data sections so that a debugger
- * can attach to us. See debug-sd-boot.sh for how this can be done. */
+/* If EFI_DEBUG, print our name and version and also report the address of the image base so a debugger can
+ * be attached. See debug-sd-boot.sh for how this can be done. */
 void notify_debugger(const char *identity, bool wait);
+
+#ifdef EFI_DEBUG
 void hexdump(const char16_t *prefix, const void *data, size_t size);
-#else
-#  define notify_debugger(i, w)
 #endif
 
 /* On x86 the compiler assumes a different incoming stack alignment than what we get.