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.
This is truely a laborous project.
I calculated that there are 264 ARM instructions to go through, and the encoding is not very 'canonical'.
Then there seems to be 329 thumb instructions.
Also the "holes" in the encoding needs to be checked, because there are lots of "UNDEFINED" in them,
meaning that executing such instruction causes UND-exception.
Then the instruction encoding is often described like:
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 op op1 op2
[EDIT]
The page seems to have been playing tricks...
'op' =bit 25, 'op1'=bits 24 - 20 and 'op2'=bits 7 - 4.
[/EDIT]
Table A5-2 shows the allocation of encodings in this space.
Table A5-2 Data-processing and miscellaneous instructions
op op1 op2 Instruction or instruction class Variant
0 not 10xx0 xxx0 Data-processing (register) on page A5-197 -
0xx1 Data-processing (register-shifted register) on page A5-198 -
10xx0 0xxx Miscellaneous instructions on page A5-207 -
1xx0 Halfword multiply and multiply accumulate on page A5-203 -
0xxxx 1001 Multiply and multiply accumulate on page A5-202 -
1xxxx 1001 Synchronization primitives on page A5-205 -
not 0xx1x 1011 Extra load/store instructions on page A5-203 -
11x1 Extra load/store instructions on page A5-203 -
0xx10 11x1 Extra load/store instructions on page A5-203 -
0xx1x 1011 Extra load/store instructions, unprivileged on page A5-204 -
0xx11 11x1 Extra load/store instructions, unprivileged on page A5-204 -
1 not 10xx0 - Data-processing (immediate) on page A5-199 -
10000 - 16-bit immediate load, MOV (immediate) on page A8-484 v6T2
10100 - High halfword 16-bit immediate load, MOVT on page A8-491 v6T2
10x10 - MSR (immediate), and hints on page A5-206 -
Really fun!
I once made some code, which generated cycle-accurate code at run-time for execution.
Doing that on Cortex-M is not easy, because constants are chopped into small bits and pieces, plus they're moved around.
Generating code on-the-fly is a challenge, because creating those constants may take too long, compared to how long it takes to execute the code.
I would have expected that the MOVW instruction had a 16-bit immediate value that would go unmodified into the instruction, but it was not like that, thus I ended up with a different solution.
BTW: if you want to format your edits, you can click the "Use advanced editor" in the top right-hand corner. Then switch to the HTML editor and change the font to ...
Monaco, Courier, mono-space; after that, click "Use advanced editor" again, now the editor should allow you to make some fixed-font formatting.
It takes some "getting used to", but it's possible to do it; I've done it on each of my documents, Writing your own startup code for Cortex-M was the first.
I can understand. I couldn't avoid seeing the Thumb encodings while going through ARM encodings in the ARMv7-A/R ARM.
I'm sweating blood for just thinking about going through the Thumb instructions.
(There are still a lot of ARM instructions to do.)
BTW: if you want to format your edits, you can click the "Use advanced editor" in the top right-hand corner. Then switch to the HTML editor and change the font to ... Monaco, Courier, mono-space; after that, click "Use advanced editor" again, now the editor should allow you to make some fixed-font formatting.
Thanks for the hint.
(BTW, nice tutorial)
I wish you good wind on getting through the remaining instructions!
-Great that you got the fixed font working (you can also use 'view source' on one of my tutorials, to see what HTML code I've used, because in some cases it was necessary to do special edits; like the Monaco font, because it's not available from the menu).
There are a few other tutorials. I promised a series of tutorials on basic math on the Cortex-M: http://community.arm.com/docs/DOC-9653 .
Hopefully I can find some time to release the next part soon.
The idea is to provide something for both beginners and experienced programmers.
Beginners will get the basics, experienced programmers might be able to find some useful tips and tricks now and then.
You probably know the GNU Assembler well by now, but perhaps you can find something interesting in the article about the macros.
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.