Breakpoints need to be disabled before we detach from the debugee.
I noticed this while looking into the fact that if you continue
executing a program in sdb (/bin/ls) where you had previously
set a breakpoint, it would crash on sdb exit once the debugee died
with an assert on HashMap destruction where we were iterating
while clearing is set. This change also happens to fix this assert.
After hitting a breakpoint, we single step the program to execute the
instruction we breaked on and re-enable the breakpoint.
We also single step the program when the user of LibDebug returned a
DebugDecision::SingleStep.
Previously, if we hit a breakpoint and then were asked to to a
DebugDecision::SingleStep, we would single step twice.
This bug can actually crash programs, because it might cause us to
skip over a patched INT3 instruction in the second single-step.
Interestingely enough, this bug manifested as functrace crashing
certain programs: after hitting a breakpoint on a CALL instruction,
functrace single steps the program to see where the CALL jumps to
(yes, this can be optimized :D). functrace crashed when a CALL
instruction jumps to another CALL, because it inserts breakpoints on CALL
instructions, and so the INT3 in the 2nd CALL was skipped over, and we
executed garbage :).
This commit fixes this by making sure not to single-step twice.
When the user of the DebugSession uses this decision, the debugged
program will be continued until it is either stopped by a singal (e.g
as a reuslt of a breakpoint), or enters a syscall.
functrace traces the function calls a program makes.
It's like strace, but for userspace.
It works by using Debugging functionality to insert breakpoints
at call&ret instructions.
2020-04-16 11:17:33 +02:00
Renamed from Applications/Debugger/DebugSession.cpp (Browse further)
