[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: step-jump-cont-strict



> (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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]