SymbX/systemd
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
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-24 04:34:56 +09:00
committed by Yu Watanabe
parent a1a4bbea2d
commit badea0d6df
3 changed files with 24 additions and 29 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/HACKING.md
+10 -17
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