Has anybody come across a list of ARM & THUMB instructions that cause deviation from the linear instruction stream?
I've been trying to figure out gdb-stub single stepping using software interrupts, and in single stepping you need to find
the next instruction(s) where the next breakpoint instruction needs to be set.
There are three cases:
1) current instruction doesn't change the execution path. Next instruction is the next word.
2) current instruction is a jump. The operand defines the next instruction address
3) current instruction is conditional branch. One possible next instruction is the next word, the other possible
instruction address is defined by the operand. (That includes conditional add with PC as the target, and the like).
To implement single stepping, I need to tell those cases apart and figure out how to find out the possible branching address.
I could go through manuals of numerous processors instruction by instruction and maybe I'd be done within the next couple of years,
or I could find a list of instructions to check, or a paper that explains how to "decode" the instructions in a useful way.
Also, there doesn't seem to be lots of sources of ARM gdb servers or stubs around that use software breakpoints.
I wish you good wind on getting through the remaining instructions!
There seems to be a great deal of wind, but unfortunately foul wind.
(I just found another table according to which, there are groups of instructions in an area I thought I already finished.)
Your tutorials seem interesting. I have used GAS yes, but my very first ARM assembly code is in the github (this project) for everyone to see and have some laughs.
I just had a look, and I don't think it's bad.
You may want to add #4 to r4 and r6 when copying, because they're 32-bit pointers.
-This can be done automatically by postfixing the ldr/str instructions by ,#4 ...
ldr r7,[r4],#4
str r7,[r6],#4
cmp r4, r5
bmi loop$
-It should be slightly faster.
Yes, of course. Thanks. At the time I wrote it, I was probably so anxious I messed up bytes and words in my mind.
I think ARM could have done the loop still, but slower due to "misalignment" and the bytes (most of them) would have been copied 4 times?
In that (You checked the start.S?) code, it copies the stub at a higher memory leaving the default addresses for debuggee.
The start1.c is not really needed, but I left it there as an example how to get symbol values from linker script and maybe (later) preparing the boot arguments. Maybe I'll add serial baud setting that way.
Correct. The data would have been copied and the misalignment would cause a slowdown.
Unfortunately, the misalignment slowdown is not just 2 reads/writes, it's 3: b+h+b.
Yes, it was start.S I had a look at, sorry, I forgot to mention that - but it was the only assembly language file I found.