jD91mZM2
6a3825d408
This is a curious problem and it's really hard to solve it in a way that doesn't feel hacky. On one hand, of course you want to be able to modify and intercept what happens when you use a signal, right? On the other hand, changes made to the context (especially singlestepping) while a signal is handled (such as `SIGSTOP`) are not preserved since the stack is restored after the signal handler was invoked. I think what we have in this change makes sense anyway, as we don't really want users modifying registers and other data in the default signal behavior that occurs **in kernel mode**. Also trying to use `PTRACE_SINGLESTEP` will set the singlestep flag only if in a user-mode signal handler, else it will set it on the instruction after the signal handling, which I guess makes sense since it can't affect the kernel-mode code that runs the default handler. I don't know. Help. Pls.
kernel
Redox OS Microkernel
Debugging the redox kernel
Running qemu with the -s flag will set up qemu to listen on port 1234 for
a gdb client to connect to it. To debug the redox kernel run.
make qemu debug=yes
This will start a VM with and listen on port 1234 for a gdb or lldb client.
gdb
If you are going to use gdb, run the following to load debug symbols and connect to your running kernel.
(gdb) symbol-file build/kernel.sym
(gdb) target remote localhost:1234
lldb
If you are going to use lldb, run the following to start debugging.
(lldb) target create -s build/kernel.sym build/kernel
(lldb) gdb-remote localhost:1234
Debugging
After connecting to your kernel you can set some interesting breakpoints and continue
the process. See your debuggers man page for more information on useful commands to run.