Stepping into function generates EXC_BAD_INSTRUCTION signal

I was just about writing up such an example as your new messages came in. I also wonder: would the trap get executed at all if the condition is not meet? From what i saw when testing things, the CPU seems to have skipped the trap (because the condition wasn’t meet) and then tried to execute the next 2-byte instruction (which was bogus, as it was the second half of the overwritten 4-byte instruction). E.g.

mov r0, 0
cmp r0, 0
it ne
blne 0x…

Would be turned into

mov r0, 0
cmp r0, 0
it ne
trap16
high16 of old instruction (bogus)

The CPU continues execution, hits the trap, the condition is false, so it skips the instruction. We never get the trap signal. The CPU then executes the high16 bits of the old instruction, which are bogus and sends us EXC_BAD_INSTRUCTION.

It gets even more interesting i believe. According to http://community.arm.com/groups/processors/blog/2010/09/30/condition-codes-3-conditional-execution-in-thumb-2 any instructions in the IT block have to have the same condition bits set as the IT itself. I’m not sure that happens with the 2-byte trap instruction?

So there's two issues here. The more crucial one is how do we step over the IT & the instructions it governs. Seems to me the answer to that - provided we can figure out that we are in this situation - is to temporarily turn off fast-stepping here.

The other issue is how would we set a breakpoint (not for stepping, but just in general) on one of the instructions governed by the IT instruction. Clearly we need to match the type of the trap to the type of instruction. If we also need to match the condition bits that makes things a little more interesting... But I think this is a second order problem, since you'd actually have to get a breakpoint on one of those instructions, which you certainly COULD do but it is probably much less common.

Jim

Sorry, i should glue the “Reply All” button. Expanding a little bit on the original message…

For issue one, an alternative solution would be to set multiple breakpoints if we find an IT in the current range. One for every branch instruction within the IT block. If there are no branch instructions within the block, we continue scanning until we hit one (either in another IT block, or outside an IT block, or we reach the end of the function). That way we only need to know how many and which instructions the IT block covers. Without

No idea for issue 2, rewriting IT blocks will not work as i thought.

Sorry, i should glue the "Reply All" button. Expanding a little bit on the original message...

For issue one, an alternative solution would be to set multiple breakpoints if we find an IT in the current range. One for every branch instruction within the IT block. If there are no branch instructions within the block, we continue scanning until we hit one (either in another IT block, or outside an IT block, or we reach the end of the function). That way we only need to know how many and which instructions the IT block covers. Without

Note, for your alternative to work, you would need to solve issue 2, since it relies on successfully setting breakpoints on the instructions in the IT block...

Jim