bug-gnu-utils
[Top][All Lists]
Advanced

[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

Attachment: bug.txt
Description: Text document

Attachment: sample.tgz
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]