> Thanks for the quick response. I am aware of some of the special > instructions that need special care when single stepping on the PPC (but > can't say I really understand the details).
SMP locking is done by sequences of at least three instructions that must all three execute uninterrupted to succeed. If the sequence is interrupted for any reason, it will loop and repeat to try again. Normal single-step always interrupts the sequence, so it can never succeed. > Don't you think this is the sort of thing that utrace single-stepping > should handle so that every utrace client doesn't have to figure this > out? gdb identifies certain non-steppable instr sequences and does some > flow analysis to set a bpt at the first steppable instr. I wholeheartedly agree that this should be implemented in code shared by all engines that need it. It is already on my list. However, that does not mean that the lowest-level feature should do that. The basic simple semantics (so far always in hardware) is what UTRACE_ACTION_SINGLESTEP enables. > Or, perhaps this should be done in the kernel, > arch/<arch>/kernel/traps.c. In the arch=powerpc cash it looks like there > is code there to emulate single stepping in certain scenarios. Paul? When the lowest-level implementation actually works by pure emulation, then I can see more of an argument for having that do the fancy business directly. This is not the case on powerpc. The code you're referring to has to do with emulating unsupported chip features and the like, and is far from a complete emulation. The basic implementation of single-step is just the hardware feature. I have discussed before decomposing the instruction-level work involved in the SSOOL implementations (a la kprobes and uprobes). I've talked about this for the purpose of breakpoint assistance. What we might call step assistance will be another beneficiary of that modularization. For machines without hardware single-step and where pure emulation is not desireable or easy enough to implement, step assistance can simulate it. For machines without hardware block-step, step assistance can simulate that. The facility for step assistance can identify atomic-sequence instructions so a stepper can decide to treat them specially. Stepping over an atomic sequence in the desired way is almost the same as block-step simulation. In this manner, I anticipate filling the needs for smarter stepping in a shared component that all clients wanting it will use. This approach has many complications and entanglements. It may be impractical for a very naive client to employ it in all situations without bad interactions it doesn't understand. It's not entirely trivial to implement all the pieces of the puzzle for a particular architecture. Special treatment of any instructions (such as atomic sequences) certainly breaks strict compatibility with what PTRACE_SINGLESTEP has meant before (even if that seems desireable, it may have unanticipated consequences for some existing application). For these reasons, I do not see it being integrated into the lowest level of the implementation as you suggest. Pure emulation does not suffer from most of these issues. Its performance is probably fine (taking traps is expensive too). But, on many machines it may be an excessive effort to implement and maintain with robust handling of all corners of behavior of all instructions. Thanks, Roland
