> (It was intentional - the code was much shorter and I would like to keep there > a difference between full-blown debugger and a simple testcase - as one GDB > testsuite already exists. Still some simplifications make it possibly not > worth the insufficiencies - as the duplicated blocks in > `user-regs-peekpoke.c', > also all the code duplications instead of a single include file may not be > worth it, particularly the peekuser/pokeuser triplicity in > `step-jump-cont-strict.c' being used in various forms in the other testcases.)
I understand. The main thrust of ptrace-tests is to have individual files that are easy to build and test on their own, so they can be passed around among kernel hackers. Displaying a little info rather than just aborting goes a long way to making the kernel debugging easier, without much effort in the test-writing. Use your judgment. If someone debugging the kernel problem would always wind up editting the test by hand with a one-liner to see what's going on, then it's probably worth writing the one line ahead of time. That's all. > My mistake there was expecting the CPU stops in PTRACE_SINGLEBLOCK after > `orl $0x100, %eflags'. This does not happen as PTRACE_SINGLEBLOCK already has > TF set and uses WRMSR to differ from PTRACE_SINGLESTEP. In this respect > PTRACE_SINGLEBLOCK behaves more like PTRACE_SINGLESTEP than PTRACE_CONT. Right. I'm following up now just to cover any loose ends in this discussion. There are still some loose ends in the code, and I'm tabling that for a bit. (Spent way too much time on tiny corners of x86 stepping already, and I've got to fry some bigger fish before I get back to the remaining nits.) Thanks, Roland
