Unexpected ARM object code from arm-elf-as

OP #2910118
Rate this post
useful
not useful
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>
#2910501
Rate this post
useful
not useful
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.
OP #2910507
Rate this post
useful
not useful
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$
OP #2910556
Rate this post
useful
not useful
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>
#2910570
Rate this post
useful
not useful
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.

Reply

Please log in before posting.

or

Log in with Google account

Registration is free and takes only a minute.

Register now