e1e554a382
off single-stepping). Only do this on arches (only x86 so far) which classify single-step traps unambiguously. This allows other parts of the kernel to be intentionally and unintentionally sloppy about generating single-step traps. On x86, at least the following places were unintentionally sloppy: - all operations that context-switched [er]flags. Especially spinlock_enter()/exit() and cpu_switch(). When single-stepped, saving the flags leaves PSL_T set in the saved flags, so restoring gives a trap that is spurious if it occurs after single-step mode has been left. Switching contexts away from a low priority thread gives especially long-lived saved copies. - the vm86 emulation allows user mode to set PSL_T. This was correct until vm86 bios call mode was unintentionally given access to kdb handling its single-step traps. Now these places are intentionally sloppy, but unexpected debugger traps still cause panics if no debugger that handles the trap is attached when the trap is delivered. |
||
|---|---|---|
| .. | ||
| db_access.c | ||
| db_access.h | ||
| db_break.c | ||
| db_break.h | ||
| db_capture.c | ||
| db_command.c | ||
| db_command.h | ||
| db_examine.c | ||
| db_expr.c | ||
| db_input.c | ||
| db_lex.c | ||
| db_lex.h | ||
| db_main.c | ||
| db_output.c | ||
| db_output.h | ||
| db_print.c | ||
| db_ps.c | ||
| db_run.c | ||
| db_script.c | ||
| db_sym.c | ||
| db_sym.h | ||
| db_textdump.c | ||
| db_thread.c | ||
| db_variables.c | ||
| db_variables.h | ||
| db_watch.c | ||
| db_watch.h | ||
| db_write_cmd.c | ||
| ddb.h | ||