Linker bug report for ARC processor

[Lucas Lin]

Bug 1:
Subject : arc-elf-ld generate the wrong offset address of relocation
entries.
Symptons:
        Linker version: snapshot version  20011003 downloaded from 

        
ftp://sources.redhat.com/pub/binutils/snapshots/binutils-20011003.tar.bz2

        When several object files are linked into a relocatable object using
        "arc-elf-ld -r" command, the relocation entries of  ".rodata"
section are
        wrong.

        Our test case is as followed:

        1. We have several object files : crt0.o main.o , test1.o printf.o 
             main.o is made by main.c, test1.o by test1.c, printf.o by
printf.c, crt0.o by crt0.s
        
        2. Create a relocatable object file core.r
             arc-elf-ld -r crt0.o main.o test1.o printf.o -o core.r

        3. The test1.c has a statement as followed:
                printf("test1\n");
             The "test1\n" string is located at the offset 0x00000000 in
".rodata" section of
             test1.o.
             This statement is translated into ARC assembly language:
                mov     r0, 0           # r0 = offset of "test\n" string in
".rodata section in test1.o
                bl      _printf         # call printf


             main.o also has a ".rodata" section of size 0x00000010.

             After linking into a relocatable object , core.r, the "test1\n"
string in ".rodata"
             section of core.r  should be 0x00000010.
             But the machine instruction in core.r does not reflect the
relocated address of
             "test1\n" string. The above ARC assembly codes should be
adjusted as followed:
                mov     r0, 0x10                # r0 = offset of "test\n"
string in ".rodata" section in core.r
                bl      _printf         # call printf
                

        4. Attached is a test program to test the bug. Just say "make test"
to verify the linker bug.
============================================================================
====

Bug 2:
Subject:    Assember wouldn't accept the "ld r0, [32]" instruction.
Symptom:
        This is actually a assembler bug rather than a linker bug, but I
don't know whether you guys
        are going to fix this. 

        If I write a C program like this:

        {
         unsigned int * ptr;

         ptr = (unsigned int *) 32;
         
         printf("%u", *ptr);
        }

        The above C program would be translated into assembly languages
using

         arc-elf-gcc -O2 -S test.c

        ....
        ld      r0, [32]                        # r0 = content of memory
address 32
        ...

        Assembler (arc-elf-ld version snapshot 20011003) would complain:
        test.s:14: Error: ld operand error

        The test.s is also contained in the attached file.


============================================================================
=====

Sincerely,

        LucasLin.

bugtest.tgz
Description: Binary data