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.
This commit is contained in:
Zbigniew Jędrzejewski-Szmek 2023-05-19 17:18:41 +02:00 committed by Yu Watanabe
parent a1a4bbea2d
commit badea0d6df
3 changed files with 24 additions and 29 deletions

View file

@ -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:
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.
```
(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.
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

View file

@ -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) {

View file

@ -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.