3rd-party/linux-kernel-module-cheat
1
0
Fork 0
mirror of https://github.com/cirosantilli/linux-kernel-module-cheat.git synced 2026-01-26 11:41:35 +01:00
Code Issues Releases Wiki Activity

run kind of runs

Browse Source
This commit is contained in:
Ciro Santilli 六四事件 法轮功
2018-12-09 00:00:01 +00:00
parent 5e20ba833b
commit fa1e4ffa7d
34 changed files with 848 additions and 838 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
README.adoc
View File

@@ -960,7 +960,7 @@ This automatically clears the GDB pane, and starts a new one.
Pass extra GDB arguments with:
....
./run --wait-gdb --tmux=start_kernel
./run --wait-gdb --tmux --tmux-args start_kernel
....
See the tmux manual for further details:
@@ -2986,7 +2986,8 @@ Or alternatively, if you are using <<tmux>>, do everything in one go with:
./run \
--arch aarch64 \
--userland print_argv \
--tmux=main \
--tmux \
--tmux-args main \
--wait-gdb \
-- \
asdf qwer \
@@ -5056,7 +5057,7 @@ If `CONFIG_KALLSYMS=n`, then addresses are shown on traces instead of symbol plu
In v4.16 it does not seem possible to configure that at runtime. GDB step debugging with:
....
./run --eval-after 'insmod /dump_stack.ko' --wait-gdb --tmux=dump_stack
./run --eval-after 'insmod /dump_stack.ko' --wait-gdb --tmux --tmux-args dump_stack
....
shows that traces are printed at `arch/x86/kernel/dumpstack.c`:
@@ -8168,7 +8169,7 @@ And in QEMU:
Or for a faster development loop:
....
./run --debug-vm='-ex "break edu_mmio_read" -ex "run"'
./run --debug-vm --debug-vm-args '-ex "break edu_mmio_read" -ex "run"'
....
When in <<qemu-text-mode>>, using `--debug-vm` makes Ctrl-C not get passed to the QEMU guest anymore: it is instead captured by GDB itself, so allow breaking. So e.g. you won't be able to easily quit from a guest program like:
@@ -10259,13 +10260,13 @@ then on the second shell:
Or if you are a <<tmux,tmux pro>>, do everything in one go with:
....
./run --arch arm --baremetal interactive/prompt --wait-gdb --tmux=main
./run --arch arm --baremetal interactive/prompt --wait-gdb --tmux --tmux-args main
....
Alternatively, to start from the very first executed instruction of our tiny <<baremetal-bootloaders>>:
....
./run --arch arm --baremetal interactive/prompt --wait-gdb --tmux=--no-continue
./run --arch arm --baremetal interactive/prompt --wait-gdb --tmux --tmux-args --no-continue
....
Now you can just `stepi` to when jumping into main to go to the C code in link:baremetal/interactive/prompt.c[].
@@ -10273,7 +10274,7 @@ Now you can just `stepi` to when jumping into main to go to the C code in link:b
This is specially interesting for the executables that don't use the bootloader from under `baremetal/arch/<arch>/no_bootloader/*.S`, e.g.:
....
./run --arch arm --baremetal arch/arm/no_bootloader/semihost_exit --wait-gdb --tmux=--no-continue
./run --arch arm --baremetal arch/arm/no_bootloader/semihost_exit --wait-gdb --tmux --tmux-args --no-continue
....
The cool thing about those examples is that you start at the very first instruction of your program, which gives more control.