#6751: gdb won't single step ----------------------------------------------+---------------------------- Reporter: grahamh | Owner: bonefish Type: bug | Status: in-progress Priority: normal | Milestone: R1 Component: Applications/Command Line Tools | Version: Resolution: | R1/Development Blocked By: | Keywords: Platform: x86 | Has a Patch: 0 | Blocking: ----------------------------------------------+---------------------------- Comment (by bonefish): Replying to [comment:8 grahamh]: > After some more investigation, here is what I think is happening. > > Asking for a single-step in gdb sends a message to the in-kernel debug facility, which sets the CPU's single-step flag in the context of the debugged thread. When the thread is resumed, it executes one instruction, then traps with an INT1 debug exception. The INT1 handler passes control to the generic trap handler, which calls gInterruptHandlerTable[1], which is x86_handle_debug_exception. So far, so good. > > The first that x86_handle_debug_exception() does is look at DR6 and DR7 to work out what kind of debug event this is. However, if the exception was from user space ( IFRAME_IS_USER(frame) ), it uses supposedly cached copies of the DRs from the thread's cpu info struct. The comment above that line says that they should have been saved by x86_exit_user_debug_at_kernel_entry - but as we have seen, that function isn't in the execution chain here. You have either omitted them intentionally or you're missing a few details here. If you have a look at `src/system/kernel/arch/x86/arch_interrupts.S`, this is where the magic is supposed to happen. On any exception (save the double fault) `int_bottom` is entered. There we check whether we came from userland and, if so, continue in `int_bottom_user`. The `DISABLE_BREAKPOINTS()` macro is where we call `x86_exit_user_debug_at_kernel_entry()`, when the `THREAD_FLAGS_BREAKPOINTS_INSTALLED` thread flag is set. I haven't checked the details yet, but I guess the problem is that this flag is only set, when there's indeed at least one breakpoint installed, i.e. not when single-stepping without any breakpoint (this would also perfectly explain the problem Rene showed me). I'll think about how to solve this without breaking what r35951/r36340 were trying to fix. Though probably not before tomorrow. -- Ticket URL: <http://dev.haiku-os.org/ticket/6751#comment:10> Haiku <http://dev.haiku-os.org> Haiku - the operating system.