[ECOS] ARM Assembler problem

[ECOS] ARM Assembler problem

[Andreas Bürgel]

Hi,

I've got following problem with GNU arm-elf-as (Host: i686-linux,
Target: ARM7TDMI):
Consider the following piece of code (simple delay loop):

  ldr     r2, .WAIT
loop:        
  sub     r2, r2, #1
  cmp     r2, #0
  bne     loop
  ...
.WAIT:
  .word   0x1000000

After assembling with "arm-elf-as -marm7tdmi file.S"
I had a closer look to a.out with "arm-elf-objdump -d a.out" and found 
      ...  
2c:   e59f2038    ldr     r2, [pc, #38]   ; 6c <.WAIT>
 
00000030 <loop>:
30:   e2422001    sub     r2, r2, #1      ; 0x1
34:   e3520000    cmp     r2, #0  ; 0x0
38:   1afffffe    bne     38 <loop+0x8>     
      ...
As you can see the assembler computed a wrong target address (opcode
1afffffe at address 38). The offset should be -2 resulting in an opcode
of 1afffffc. If I use a hex-editor to change the opcode in the binary
image, the program works as expected.

Is there a special option I forgot or is the assembler buggy (resp.
built wrong). Thanks in advance.

Re: [ECOS] ARM Assembler problem

[Jonathan Larmour]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 559 bytes --]

Andreas Bürgel wrote:
> 
> I've got following problem with GNU arm-elf-as (Host: i686-linux,
> Target: ARM7TDMI):
[snip]
> As you can see the assembler computed a wrong target address (opcode
[snip]

If this isn't binutils 2.10.1, try that instead. If that fails similarly,
try the list binutils@sources.redhat.com (see
http://sources.redhat.com/binutils ). The ARM gas maintainers lurk there.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

Re: [ECOS] ARM Assembler problem

[Grant Edwards]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2351 bytes --]

On Tue, Nov 28, 2000 at 03:42:16PM +0100, Andreas Bürgel wrote:

> I've got following problem with GNU arm-elf-as (Host: i686-linux,
> Target: ARM7TDMI):
> Consider the following piece of code (simple delay loop):
> 
>   ldr     r2, .WAIT
> loop:        
>   sub     r2, r2, #1
>   cmp     r2, #0
>   bne     loop
>   ...
> .WAIT:
>   .word   0x1000000
> 
> After assembling with "arm-elf-as -marm7tdmi file.S"
> I had a closer look to a.out with "arm-elf-objdump -d a.out" and found 
>       ...  
> 2c:   e59f2038    ldr     r2, [pc, #38]   ; 6c <.WAIT>
>  
> 00000030 <loop>:
> 30:   e2422001    sub     r2, r2, #1      ; 0x1
> 34:   e3520000    cmp     r2, #0  ; 0x0
> 38:   1afffffe    bne     38 <loop+0x8>     
>       ...
> As you can see the assembler computed a wrong target address (opcode
> 1afffffe at address 38). The offset should be -2 resulting in an opcode
> of 1afffffc. If I use a hex-editor to change the opcode in the binary
> image, the program works as expected.

I get the same result you do when dumping the object file
created by the compiler, but once I link the file, I get the
correct dump.  I presume that the branch instruction in the
first object file is still relocatable (even though it doesn't
need to be), and objdump isn't displaying it properly.  You may
want to report this as a bug to the binutils mailing list.
Once the file has been linked and the relocations resolved, it
disassembles correclty:

$ arm-elf-as -marm7tdmi -o file.o file.s
$ arm-elf-objdump --source file.o
[...]
00000000 <loop-0x4>:
   0:   e59f2008        ldr     r2, [pc, #8]    ; 10 <delay>
00000004 <loop>:
   4:   e2422001        sub     r2, r2, #1      ; 0x1
   8:   e3520000        cmp     r2, #0  ; 0x0
   c:   1affffff        bne     10 <delay>
00000010 <delay>:
  10:   01000000        tsteq   r0, r0
  
$ arm-elf-ld -o file.a file.o
arm-elf-ld: warning: cannot find entry symbol _start; defaulting to 00008000
$ arm-elf-objdump --source file.a
[...]
00008000 <loop-0x4>:
    8000:       e59f2008        ldr     r2, [pc, #8]    ; 8010 <delay>
00008004 <loop>:
    8004:       e2422001        sub     r2, r2, #1      ; 0x1
    8008:       e3520000        cmp     r2, #0  ; 0x0
    800c:       1afffffc        bne     8004 <loop>
00008010 <delay>:
    8010:       01000000        tsteq   r0, r0

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] ARM Assembler problem

[Jonathan Larmour]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1102 bytes --]

Jonathan Larmour wrote:
> 
> Andreas Bürgel wrote:
> >
> > I've got following problem with GNU arm-elf-as (Host: i686-linux,
> > Target: ARM7TDMI):
> [snip]
> > As you can see the assembler computed a wrong target address (opcode
> [snip]
> 
> If this isn't binutils 2.10.1, try that instead. If that fails similarly,
> try the list binutils@sources.redhat.com (see
> http://sources.redhat.com/binutils ). The ARM gas maintainers lurk there.

I should have thought more before speaking actually. I quickly tried it and
realised what your problem is.... you are assuming that the output of the
assembler is something that can be used directly. It is not, it is an
intermediate object file (.o file).

Even though it *seems* easy enough for the assembler to just use a relative
branch, it is still left up to the linker to actually fill in the
relocations.

So once you have linked your program, the disassembly should be what you
expect.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault