Jump addresses messed up with GNU as

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

Reply to
Sebastien
Loading thread data ...

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
Reply to
Tauno Voipio

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.

Reply to
Sebastien

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

Reply to
Sebastien

Yes, it is. Do you use linker?

Vadim

Reply to
Vadim Borshchev

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

Reply to
Sebastien

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

Reply to
Sebastien

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

Reply to
Vadim Borshchev

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

Vadim

Reply to
Vadim Borshchev

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.