Jump addresses messed up with GNU as

Jul 26, 2005 8 Replies

Hello,



I'm trying to assemble the following program (ARM architecture) :



.text nop



1: nop nop nop bal 1b

GNU as produces the following code (read back with objdump -d) : Disassembly of section .text:


00000000 : 0: e1a00000 nop (mov r0,r0) 4: e1a00000 nop (mov r0,r0) 8: e1a00000 nop (mov r0,r0) c: e1a00000 nop (mov r0,r0) 10: eaffffff b 14

As you can see, the address for the jump is outside the program :( I assemble with the following command : arm-elf-as -mcpu=arm7tdmi -o myprog.o myprog.s



The problem's exactly the same when not using a local label. Any ideas ? Thanks, Sebastien



I just wonder:

Which version is your objdump?

Mine produced the following output:

temp$ arm-elf-objdump -D xyz.o

xyz.o: file format elf32-littlearm

Disassembly of section .text:

00000000 : 0: e1a00000 nop (mov r0,r0) 4: e1a00000 nop (mov r0,r0) 8: e1a00000 nop (mov r0,r0) c: e1a00000 nop (mov r0,r0) 10: eaffffff b 0x4 Disassembly of section .data:

My assembler and other binary utilities are of version 2.14.

Tauno Voipio tauno voipio (at) iki fi

GNU objdump 2.15 [FreeBSD] 2004-05-23

The problem does not come from objdump, but from the assembler itself, if I specify the address manually, objdump produces the correct output (and my program works when I load it into the CPU). I found out that the assembler adds the current address to the label address... The workaround is to use "b label-." instead of "b label" ; but that's quite dirty.

Oops, I took my native objdump (that's where the "FreeBSD" comes from). But my ARM objdump is 2.15 too.

Yes, it is. Do you use linker?

Vadim

I didn't. But I have a similar problem when using GCC (I downgraded to GCC

3.4.3 and Binutils 2.14 to see if it was a GCC4 bug, but it is not), for example with the following program :

int main(void) { int i; for(i=0;i

Ah, that's pretty stupid, I used main.o instead of monitor.o Works much better now :)

Do I understand you right that you are loading and executing the code from the object file (main.o) *before* you have it linked into executable?

Vadim

No, I didn't. Semantic confusion over "-o monitor.o main.o" part.

Vadim

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required