[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Bug report on GNU linker for ARC processor
From: |
Lucas Lin |
Subject: |
Bug report on GNU linker for ARC processor |
Date: |
Thu, 2 Aug 2001 15:39:52 +0800 |
Dear Binutils maintainers:
Attached is the bug we hit recently. We've tried to
downloaded
the latest GNU software , but failed to solve the problem.
I am not sure the bug we hit is really a bug or not. My developing
environment is Linux 2.2.12 ( Red Hat 6.1).
Could you tell us whether it is a bug , or there is some work-around
to the problem??
Sincerely,
LucasLin address@hidden
============================================================================
Subject: LD bug for arc processor
Description:
GNU LD version : 2.11.2 (which is the latest version when
this report is written).
GCC version: 2.95.3
When several object files are linked together, the gnu
LD for arc-elf computes the wrong "relative address" for
"bl" instruction.
For example, we wrote the following assembly codes which
called etmain subroutine in C file:
====== crt0.s ======
....
bl.nd _etmain
....
====== main.c ======
int etmain(void)
{
return(0);
}
When I looked at the symbol table in the final linked
object code ( target.hex in Motorola S record format),
the value of _etmain symbol and the address which "bl"
jumps to does not match.
If the "bl" target resides in the same object file as the
"bl" instruction, then the "bl" relative address is
correctly computed by assembler. If the called target
subroutine resides in different file to the caller
subroutine, the the relative address is incorrectly
computed by LD program.
Here is the symbol table which NM produce:
...
00900124 t _test1
00900144 t _test2
00900164 T _dummy
00900194 T _etmain
009001dc T _aloha
...
And here is the result of OBJDUMP:
00900000 <.sec1>:
900000: 00 80 bf 1f 1fbf8000 flag 0
< deleted >
90010c: 80 0d 00 28 28000d80 bl 0x90017c
<wrong offset!>
900110: 00 02 00 28 28000200 bl 0x900124
<correct offset computed>
900114: 01 80 bf 1f 1fbf8001 flag 1
900118: ff ff ff 7f 7fffffff nop
90011c: ff ff ff 7f 7fffffff nop
900120: ff ff ff 7f 7fffffff nop
< _test1: >
900124: 04 3e 0e 10 100e3e04 st blink,[sp,4]
900128: 00 36 0e 10 100e3600 st fp,[sp]
90012c: 00 38 6e 63 636e3800 mov fp,sp
900130: 10 7e 8e 53 538e7e10 sub sp,sp,16
900134: 80 01 00 28 28000180 bl 0x900144
900138: 04 80 ed 0b 0bed8004 ld blink,[fp,4]
90013c: 20 80 0f 38 380f8020 j.d [blink]
900140: 10 10 6e 0b 0b6e1010 ld.a fp,[sp,16]
900144: 04 3e 0e 10 100e3e04 st blink,[sp,4]
900148: 00 36 0e 10 100e3600 st fp,[sp]
90014c: 00 38 6e 63 636e3800 mov fp,sp
900150: 10 7e 8e 53 538e7e10 sub sp,sp,16
900154: ff ff ff 7f 7fffffff nop
900158: 04 80 ed 0b 0bed8004 ld blink,[fp,4]
90015c: 20 80 0f 38 380f8020 j.d [blink]
900160: 10 10 6e 0b 0b6e1010 ld.a fp,[sp,16]
900164: 00 36 0e 10 100e3600 st fp,[sp]
900168: 00 38 6e 63 636e3800 mov fp,sp
90016c: 00 10 6e 0b 0b6e1000 ld.a fp,[sp]
900170: 20 80 0f 38 380f8020 j.d [blink]
900174: 00 02 00 40 40000200 add r0,r0,r1
< _etmain: >
900178: 04 3e 0e 10 100e3e04 st blink,[sp,4]
90017c: 00 36 0e 10 100e3600 st fp,[sp]
900180: 00 38 6e 63 636e3800 mov fp,sp
900184: 10 7e 8e 53 538e7e10 sub sp,sp,16
900188: 05 fe 1f 60 601ffe05 mov r0,5
90018c: a0 02 00 28 280002a0 bl.d 0x9001a4
<Oops, wrong offset again>
900190: 06 fe 3f 60 603ffe06 mov r1,6
900194: 04 80 ed 0b 0bed8004 ld blink,[fp,4]
900198: 20 80 0f 38 380f8020 j.d [blink]
90019c: 10 10 6e 0b 0b6e1010 ld.a fp,[sp,16]
< _aloha: >
9001a0: 00 36 0e 10 100e3600 st fp,[sp]
9001a4: 00 38 6e 63 636e3800 mov fp,sp
9001a8: 00 10 6e 0b 0b6e1000 ld.a fp,[sp]
9001ac: 20 80 0f 38 380f8020 j.d [blink]
9001b0: 00 02 00 40 40000200 add r0,r0,r1
============================================================================
Lucas Lin etBIOS, VIA Technologies, Inc.
8F., 533 Chung-Cheng Road,
Hsin-Tien, Taipei
Taiwan, R.O.C.
(8862) 2218-5452 x 6470
(8862) 2218-9858 fax
address@hidden
bug.txt
Description: Text document
sample.tgz
Description: Binary data
- Bug report on GNU linker for ARC processor,
Lucas Lin <=