Hi All,
so I've assembled a really basic ARM program then disassembled it to
analyse each instruction. The encoded instruction at BNE is puzzling,
how does the processor know what address to jump to if it appears to be
different to the one embedded in the instruction?
Is a jump table involved, and if so, how to I extract that information
from the object file?
I'm assembling for an arm2 target using-
~/arm-elf-as memoryInitProgram.s -o memoryInitProgram.o
then I run this -
~/arm-elf-objdump -d memoryInitProgram.o
memoryInitProgram.o: file format elf32-littlearm
Disassembly of section .text:
00000000 <main>:
0: e3a01902 mov r1, #32768 ; 0x8000
4: e3a02c01 mov r2, #256 ; 0x100
8: e3a00000 mov r0, #0
0000000c <loop>:
c: e4810004 str r0, [r1], #4
10: e2422001 sub r2, r2, #1
14: 1a000001 bne c <loop>
Have a look here
http://www.peter-cockerell.net/aalp/html/ch-3.html
3.5 Group four - branch
Subsection - Offsets and pipelining
Ohh - And sorry my crystalball wasn't able to tell what type of arm MCU
you use.
/Bingo
Disassembling object files might not show the same machine code as later
is placed in memory, since relocations are not yet applied to it. In
case of the BNE instruction, there could be a relocation record in the
object file which associates the instruction with the symbolic target
"loop" and the exact machine code is updated by the linker, or in other
cases by the operating system loader.
Hi Bingo,
thanks for you reply, the target processor is actually software
emulated, but based on an arm2 instruction set.
I was able to figure out the ((instruction value) x Wordsize)+(pipeline
length) so I tried adding more code in the vector table area only to
find more strange output. I can't see how fffffe translates to 0x20?
memoryInitProgram.o: file format elf32-littlearm
Disassembly of section .text:
00000000 <main-0x20>:
0: eafffffe b 20 <main>
...
00000020 <main>:
20: e3a01902 mov r1, #32768 ; 0x8000
24: e3a02c01 mov r2, #256 ; 0x100
28: e3a00000 mov r0, #0
0000002c <loop>:
2c: e1a00000 nop ; (mov r0, r0)
30: e1a00000 nop ; (mov r0, r0)
34: e1a00000 nop ; (mov r0, r0)
38: e1a00000 nop ; (mov r0, r0)
3c: e4810004 str r0, [r1], #4
40: e2422001 sub r2, r2, #1
44: 1a000009 bne 2c <loop>
asdka@asdka-laptop:~/softprocessor/testARMcode$
Thanks for the tips, the trouble is, this is for testing a software
emulation of an arm processor and I really dont want extra code getting
linked in when there isn't support for it (yet).
I checked the source code and there was a .global directive at the top
of the file, this must be telling the assembler to designate the code as
relocatable. I removed this an it all makes much more sense.
asdka@asdka-laptop:~/softprocessor/testARMcode$
/home/asdka/armbinutils/bin/arm-elf-objdump -d memoryInitProgram.o
memoryInitProgram.o: file format elf32-littlearm
Disassembly of section .text:
00000000 <main-0x20>:
0: ea000006 b 20 <main>
...
00000020 <main>:
20: e3a01902 mov r1, #32768 ; 0x8000
24: e3a02c01 mov r2, #256 ; 0x100
28: e3a00000 mov r0, #0
0000002c <loop>:
2c: e1a00000 nop ; (mov r0, r0)
30: e1a00000 nop ; (mov r0, r0)
34: e1a00000 nop ; (mov r0, r0)
38: e1a00000 nop ; (mov r0, r0)
3c: e4810004 str r0, [r1], #4
40: e2422001 sub r2, r2, #1
44: 1a000009 bne 2c <loop>
You really should check the binutils' manual to find out whether as is
actually able to produce unrelocated code, and if so, how, if you indent
to analyse and perhaps run .o based code. Otherwise you might just end
with a section based relocation instead of a symbol based relocation, in
places where absolute addresses are encoded instead of relative
addresses.