CC'ing linaro-kernel@lists.linaro.org and dropping other CC's...
On Fri, 2011-03-18 at 13:20 +0000, Dave Martin wrote:
On Fri, Mar 18, 2011 at 7:18 AM, Tixy tixy@yxit.co.uk wrote:
On Thu, 2011-03-17 at 19:08 -0400, Nicolas Pitre wrote:
On Thu, 17 Mar 2011, Tixy wrote:
[...]
I also have the first draft of a test framework so I can start working on on implementing emulation code for the rest of the Thumb instruction set, that could take a while longer ;-) (I plan on adding test cases for the current ARM instruction simulation as well).
Hmmm... How are you doing that? To me this always seemed to be as hard to make such test framework error free as ensuring that the tested code is itself error free in the first place.
True, but hopefully the bugs in each won't usually cancel each other out and lead to false test passes. Any way, I need some test code otherwise I won't have a simple way of exercising the emulation code I write.
The testing method I hit upon was this:
probe_before: nop; probe_test: add r0, r1, r2 probe_after: nop;
Pass 1:
- Insert probe_before and probe_after
- Run code
- When handler 'before' runs, modify register context with test values
- When handler 'after' runs, save register context
Pass 2:
- Insert probe_test
- Do same as Pass 1
- Verify saved register context is identical to Pass 1.
I do the above two passes twice, the second time with CPSR inverted and with the registers not used by the tested instruction also inverted (to more robustly detect if they accidentally get corrupted).
I plan on doubling up the passes as well to add setting an IT State, as some instructions behave different in an IT block by not modifying CPSR.
I'll have to add support for testing LDR, STR and friends, plus anything else as needed.
I feel that it's important to get some initial, incomplete implementation patches out for review as soon as feasible, since that gives people the best opportunity to comment or express any concerns on the implementation strategy.
I'll aim to post a patch to linaro-kernel by Monday which will have the Thumb NOP probing work. It'll act as a catalyst for discussing issues and coding decisions. I'm new to git and patches, so I'll do some tests with creating local branches and emailing patches to myself first :-)
I won't post the test code yet as that is very much work in progress, though for anyone curious I put it at http://tixy.me.uk/kprobe-test.c (I knew I would eventually find a use for the Web server I put on my Sheevaplug :-)
The testing ideas look like a good start. Can the framework be applied to ARM as well as Thumb? It looks at first glance like it can, and it would be good to cover the ARM case in the testing if there's no test framework already.
Should work with ARM as well with some small tweaking.
Branch-like instructions are an interesting case, since these often occur as specific encodings of otherwise non-branch-like instructions (for example, LDR, LDM/POP, MOV{S} etc.)
For branches, test code would need an extra probe at the branch target (and one at the instruction before to trap miscalculated branches.)
But writing test code is probably a lot less work than actually writing the simulation code in the kprobe implementation. That has to cope with all the different instruction types, the test framework would just needs one or two test types implementing.
Coming up with all the appropriate test cases could be quite a bit of work too, since there is not the same level or orthogonality in the instruction set encoding as you get with ARM.
Again, I think this is more of a problem for the implementation of kprobes, not the test cases. For Thumb, we do have some factors making it simpler that appears at first sight though...
For 16-bit instructions there are whole swathes of instructions which only operation on low registers. These can all use the same simulation code which just restores r0-r7,cpsr, executes the original instruction, then saves r0-r7,cpsr again. (I realised this after writing my first half dozen simulation functions :-)
For 32-bit instructions, many of the operations on PC are illegal or Undefined behaviour; so we can probably get away with ignoring these cases.
Cheers
On Fri, Mar 18, 2011 at 3:10 PM, Tixy tixy@yxit.co.uk wrote:
CC'ing linaro-kernel@lists.linaro.org and dropping other CC's...
On Fri, 2011-03-18 at 13:20 +0000, Dave Martin wrote:
On Fri, Mar 18, 2011 at 7:18 AM, Tixy tixy@yxit.co.uk wrote:
On Thu, 2011-03-17 at 19:08 -0400, Nicolas Pitre wrote:
On Thu, 17 Mar 2011, Tixy wrote:
[...]
I also have the first draft of a test framework so I can start working on on implementing emulation code for the rest of the Thumb instruction set, that could take a while longer ;-) (I plan on adding test cases for the current ARM instruction simulation as well).
Hmmm... How are you doing that? To me this always seemed to be as hard to make such test framework error free as ensuring that the tested code is itself error free in the first place.
True, but hopefully the bugs in each won't usually cancel each other out and lead to false test passes. Any way, I need some test code otherwise I won't have a simple way of exercising the emulation code I write.
The testing method I hit upon was this:
probe_before: nop; probe_test: add r0, r1, r2 probe_after: nop;
Pass 1:
- Insert probe_before and probe_after
- Run code
- When handler 'before' runs, modify register context with test values
- When handler 'after' runs, save register context
Pass 2:
- Insert probe_test
- Do same as Pass 1
- Verify saved register context is identical to Pass 1.
I do the above two passes twice, the second time with CPSR inverted and with the registers not used by the tested instruction also inverted (to more robustly detect if they accidentally get corrupted).
I plan on doubling up the passes as well to add setting an IT State, as some instructions behave different in an IT block by not modifying CPSR.
I'll have to add support for testing LDR, STR and friends, plus anything else as needed.
I feel that it's important to get some initial, incomplete implementation patches out for review as soon as feasible, since that gives people the best opportunity to comment or express any concerns on the implementation strategy.
I'll aim to post a patch to linaro-kernel by Monday which will have the Thumb NOP probing work. It'll act as a catalyst for discussing issues and coding decisions. I'm new to git and patches, so I'll do some tests with creating local branches and emailing patches to myself first :-)
No problem!
I won't post the test code yet as that is very much work in progress, though for anyone curious I put it at http://tixy.me.uk/kprobe-test.c (I knew I would eventually find a use for the Web server I put on my Sheevaplug :-)
The testing ideas look like a good start. Can the framework be applied to ARM as well as Thumb? It looks at first glance like it can, and it would be good to cover the ARM case in the testing if there's no test framework already.
Should work with ARM as well with some small tweaking.
Branch-like instructions are an interesting case, since these often occur as specific encodings of otherwise non-branch-like instructions (for example, LDR, LDM/POP, MOV{S} etc.)
For branches, test code would need an extra probe at the branch target (and one at the instruction before to trap miscalculated branches.)
But writing test code is probably a lot less work than actually writing the simulation code in the kprobe implementation. That has to cope with all the different instruction types, the test framework would just needs one or two test types implementing.
Coming up with all the appropriate test cases could be quite a bit of work too, since there is not the same level or orthogonality in the instruction set encoding as you get with ARM.
Again, I think this is more of a problem for the implementation of kprobes, not the test cases. For Thumb, we do have some factors making it simpler that appears at first sight though...
For 16-bit instructions there are whole swathes of instructions which only operation on low registers. These can all use the same simulation code which just restores r0-r7,cpsr, executes the original instruction, then saves r0-r7,cpsr again. (I realised this after writing my first half dozen simulation functions :-)
For 32-bit instructions, many of the operations on PC are illegal or Undefined behaviour; so we can probably get away with ignoring these cases.
Yes, that's true. For most instructions, only a special form can read the PC, and few instructions can write it.
Cheers ---Dave
linaro-kernel@lists.linaro.org
-
Dave Martin -
Tixy