> The BookE variant is superior in some ways as it allows to know where > you come from on branches. But that also means that the semantics exposed > to user space would not be consistent which is BAD (tm).
If it were me I would start with a simpler patch that doesn't implement it at all on BookE, and arch_has_block_step() yields 0 on those configs. Later on when someone using BookE asks for it, revisit the complexity. But that doesn't mean you shouldn't just go with what you've done now. The reality is that there is no user expectation established one way or another yet. For a long time only ia64 had PTRACE_SINGLEBLOCK and for not too many kernel versions has x86 had it too. There aren't yet other established uses of user_enable_block_step() so as to have an expectation of what the semantics are. arch_has_block_step() by itself does not indicate the details. If there is something more generic that starts to use this and thus cares to know exactly what "block step" means, then we can figure it out. My first inclination is to have arch code provide only what is most natural and simple on the given CPU and just have more-specific arch macros/inlines saying what the behavior is (before branch or after branch, and whether also before non-taken branches, are the only two bits of variance I can think of). Then whatever generic thing is built on this can test those and cope. i.e., a non-arch layer would be responsible for deciding that doing an immediate single-step was the useful thing to do for this CPU's flavor of block-step. But I don't feel at all strongly that you shouldn't just roll it into the arch code as you have done. It's up to you--and really it's just pending this getting exercised for any real-world purpose to see what one really wants. (Chances are such things would get done on x86 first, where they might take advantage of several flavors of branch source/target recording features. So seeing what of all that some actual tool used in practice might inform one's looking into what analogues or subsets powerpc chips have to offer.) Thanks, Roland _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev