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.
Make sure that userspace is always referencing "system" headers in a way
that would build on target :). This means removing the explicit
include_directories of Libraries/LibC in favor of having it export its
headers as SYSTEM. Also remove a redundant include_directories of
Libraries in the 'serenity build' part of the build script. It's already
set at the top.
This causes issues for the Kernel, and for crt0.o. These special cases
are handled individually.
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.h (Browse further)
