diff options
| author | Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> | 2023-05-19 17:18:41 +0200 |
|---|---|---|
| committer | Yu Watanabe <watanabe.yu+github@gmail.com> | 2023-05-23 21:34:56 +0200 |
| commit | badea0d6df2a2d3e5ac6c6d068f39ea80c2724d1 (patch) | |
| tree | 0a66ff3a1dc75d0ea2d95d65ef5af31818473853 /docs/HACKING.md | |
| parent | mkfs-util: Silence noisy warning from mkfs.btrfs (diff) | |
| download | systemd-badea0d6df2a2d3e5ac6c6d068f39ea80c2724d1.tar.xz systemd-badea0d6df2a2d3e5ac6c6d068f39ea80c2724d1.zip | |
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.
Diffstat (limited to 'docs/HACKING.md')
| -rw-r--r-- | docs/HACKING.md | 29 |
1 files changed, 11 insertions, 18 deletions
diff --git a/docs/HACKING.md b/docs/HACKING.md index 0aa9233345..6680ebc91f 100644 --- 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 |