diff options
Diffstat (limited to 'hurd/debugging/trap_in_the_kernel.mdwn')
| -rw-r--r-- | hurd/debugging/trap_in_the_kernel.mdwn | 27 |
1 files changed, 27 insertions, 0 deletions
diff --git a/hurd/debugging/trap_in_the_kernel.mdwn b/hurd/debugging/trap_in_the_kernel.mdwn new file mode 100644 index 00000000..11f989e3 --- /dev/null +++ b/hurd/debugging/trap_in_the_kernel.mdwn @@ -0,0 +1,27 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach open_issue_documentation]] + +IRC, #hurd, September 2010 + + <diegonc> when an application executes an out instruction in user mode, how is + kernel mode entered? general protection trap? + <youpi> some sort of trap, yes + <youpi> I'd rather think about illegal instruction, but yes + <diegonc> hm.. so to debug what happens inside that instruction I'll have to + break at the trap handler. Can I instruct kdb to stop only when a given task + caused the trap? + <youpi> applications usually don't trap, so what I usually do is to uncomment + the test at the end of user_trap() before the call to kdb_trap() + <diegonc> "if (debug_all_traps_with_kdb && .. " <- that test? + <youpi> yes + <youpi> so comment the test to make kdb_trap() called all the time + <diegonc> oh, I understand now :) |