From 0a5b0dae01a9d224ee10be9cd00c720483b432e9 Mon Sep 17 00:00:00 2001 From: Ingo Weinhold Date: Sat, 30 Oct 2010 11:45:04 +0000 Subject: [PATCH] Added TODO. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39202 a95241bf-73f2-0310-859d-f6bbb57e9c96 --- src/apps/debugger/ThreadHandler.cpp | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/src/apps/debugger/ThreadHandler.cpp b/src/apps/debugger/ThreadHandler.cpp index e4b3709066..023bad1bf2 100644 --- a/src/apps/debugger/ThreadHandler.cpp +++ b/src/apps/debugger/ThreadHandler.cpp @@ -263,10 +263,20 @@ ThreadHandler::HandleThreadAction(uint32 action) TRACE_CONTROL(" ip: %#llx\n", frame->InstructionPointer()); // When the thread is in a syscall, do the same for all step kinds: Stop it - // when it return by means of a breakpoint. + // when it returns by means of a breakpoint. if (frame->Type() == STACK_FRAME_TYPE_SYSCALL) { // set a breakpoint at the CPU state's instruction pointer (points to // the return address, unlike the stack frame's instruction pointer) +// TODO: This is doesn't work correctly anymore. When stepping over a "syscall" +// instruction the thread is stopped twice. The after the first step the PC is +// incorrectly shown at the "syscall" instruction. Then we step again and are +// stopped at the temporary breakpoint after the "syscall" instruction. There +// are two problems. The first one is that we don't (cannot?) discriminate +// between the thread being in a syscall (like in a blocking syscall) and the +// thread having been stopped (or singled-stepped) at the end of the syscall. +// The second issue is that the temporary breakpoint is probably not necessary +// anymore, since single-stepping over "syscall" instructions should just work +// as expected. status_t error = _InstallTemporaryBreakpoint( frame->GetCpuState()->InstructionPointer()); if (error != B_OK) {