a bit closer

gdbserver.adoc

@@ -1,8 +1,6 @@
-[[gdbserver]]
-= gdbserver
+=== gdbserver
 
-Step debug userland processes to understand how they are talking to the
-kernel.
+Step debug userland processes to understand how they are talking to the kernel.
 
 In guest:
 
@@ -24,15 +22,8 @@ find buildroot/output.x86_64~/build -name myinsmod.out
 
 TODO: automate the path finding:
 
-* using the executable from under `buildroot/output.x86_64~/target`
-would be easier as the path is the same as in guest, but unfortunately
-those executables are stripped to make the guest smaller.
-`BR2_STRIP_none=y` should disable stripping, but make the image way
-larger.
-* `outputx86_64~/staging/` would be even better than `target/` as the
-docs say that this directory contains binaries before they were
-stripped. However, only a few binaries are pre-installed there by
-default, and it seems to be a manual per package thing.
+* using the executable from under `buildroot/output.x86_64~/target` would be easier as the path is the same as in guest, but unfortunately those executables are stripped to make the guest smaller. `BR2_STRIP_none=y` should disable stripping, but make the image way larger.
+* `outputx86_64~/staging/` would be even better than `target/` as the docs say that this directory contains binaries before they were stripped. However, only a few binaries are pre-installed there by default, and it seems to be a manual per package thing.
 +
 E.g. `pciutils` has for `lspci`:
 +
@@ -44,16 +35,13 @@ define PCIUTILS_INSTALL_STAGING_CMDS
 endef
 ....
 +
-and the docs describe the `*_INSTALL_STAGING` per package config, which
-is normally set for shared library packages.
+and the docs describe the `*_INSTALL_STAGING` per package config, which is normally set for shared library packages.
 +
 Feature request: https://bugs.busybox.net/show_bug.cgi?id=10386
 
-An implementation overview can be found at:
-https://reverseengineering.stackexchange.com/questions/8829/cross-debugging-for-mips-elf-with-qemu-toolchain/16214#16214
+An implementation overview can be found at: https://reverseengineering.stackexchange.com/questions/8829/cross-debugging-for-mips-elf-with-qemu-toolchain/16214#16214
 
-[[gdbserver-different-archs]]
-== gdbserver different archs
+==== gdbserver different archs
 
 As usual, different archs work with:
 
@@ -61,8 +49,7 @@ As usual, different archs work with:
 ./rungdbserver -a arm kernel_module-1.0/user/myinsmod.out
 ....
 
-[[gdbserver-busybox]]
-== gdbserver BusyBox
+==== gdbserver BusyBox
 
 BusyBox executables are all symlinks, so if you do on guest:
 
@@ -76,11 +63,9 @@ on host you need:
 ./rungdbserver busybox-1.26.2/busybox
 ....
 
-[[gdbserver-shared-libraries]]
-== gdbserver shared libraries
+==== gdbserver shared libraries
 
-Our setup gives you the rare opportunity to step debug libc and other
-system libraries e.g. with:
+Our setup gives you the rare opportunity to step debug libc and other system libraries e.g. with:
 
 ....
 b open
@@ -99,27 +84,20 @@ This is made possible by the GDB command:
 set sysroot ${buildroot_out_dir}/staging
 ....
 
-which automatically finds unstripped shared libraries on the host for
-us.
+which automatically finds unstripped shared libraries on the host for us.
 
-See also:
-https://stackoverflow.com/questions/8611194/debugging-shared-libraries-with-gdbserver/45252113#45252113
+See also: https://stackoverflow.com/questions/8611194/debugging-shared-libraries-with-gdbserver/45252113#45252113
 
-[[debug-userland-process-without-gdbserver]]
-== Debug userland process without gdbserver
+==== Debug userland process without gdbserver
 
-QEMU `-gdb` GDB breakpoints are set on virtual addresses, so you can in
-theory debug userland processes as well.
+QEMU `-gdb` GDB breakpoints are set on virtual addresses, so you can in theory debug userland processes as well.
 
 * https://stackoverflow.com/questions/26271901/is-it-possible-to-use-gdb-and-qemu-to-debug-linux-user-space-programs-and-kernel
 * https://stackoverflow.com/questions/16273614/debug-init-on-qemu-using-gdb
 
-The only use case I can see for this is to debug the init process (and
-have fun), otherwise, why wouldn't you just use `gdbserver`? Known
-limitations of direct userland debugging:
+The only use case I can see for this is to debug the init process (and have fun), otherwise, why wouldn't you just use `gdbserver`? Known limitations of direct userland debugging:
 
-* the kernel might switch context to another process, and you would
-enter "garbage"
+* the kernel might switch context to another process, and you would enter "garbage"
 * TODO step into shared libraries. If I attempt to load them explicitly:
 +
 ....
@@ -155,8 +133,7 @@ BusyBox custom init process:
 ./rungdb-user -h busybox-1.26.2/busybox ls_main
 ....
 
-This follows BusyBox' convention of calling the main for each executable
-as `<exec>_main` since the `busybox` executable has many "mains".
+This follows BusyBox' convention of calling the main for each executable as `<exec>_main` since the `busybox` executable has many "mains".
 
 BusyBox default init process:
 
@@ -171,8 +148,7 @@ BusyBox default init process:
 ./rungdb-user -h busybox-1.26.2/busybox init_main
 ....
 
-This cannot be debugged in another way without modifying the source, or
-`/sbin/init` exits early with:
+This cannot be debugged in another way without modifying the source, or `/sbin/init` exits early with:
 
 ....
 "must be run as PID 1"
@@ -199,5 +175,4 @@ continue
 /sleep_forever.out
 ....
 
-This is of least reliable setup as there might be other processes that
-use the given virtual address.
+This is of least reliable setup as there might be other processes that use the given virtual address.