RE: Bug report on GNU linker for ARC processor

[Lucas Lin]

Hi Nick,

   I'm glad you response so quick.

   I've tried the patch, but failed to work.

   In the attached file , I transform the main.c to main.s.
   You can test the sample code again.  Don't worry about arc-elf-gcc.

   I'm sorry to send you the corrupt file in the previous tar file.


   Sincerely,

   LucasLin

-----Original Message-----
From: Nick Clifton [mailto:address@hidden
Sent: Thursday, August 02, 2001 7:00 PM
To: Lucas Lin
Cc: address@hidden; Aaron Lin; Rongwen Chang; Mark Lu
Subject: Re: Bug report on GNU linker for ARC processor


Hi Lucas,

> Could you tell us whether it is a bug , or there is some work-around 
> to the problem??

This does appear to be a real bug.  It sounds as if the ARC specific
code in the BFD library is not processing the relocs correctly.

Unfortunately the Linkcmd script in the tar file you attached appears
to be corrupt (it contained binary data not text).  Also since I do
not have a copy of arc-gcc built (and I am lazy!) I was not able to
build alpha.o and main.o.  Instead I created a little stub file like
this:

        .text
        .global _etmain
  _etmain:
        nop
        .global start
  start:
        nop
        
        .data
        .global _stack_high
  _stack_high:
        .word 0

which I assembled and linked with crt0.o.  This then appeared to
demonstrate the problem since the 'bl.nd _etmain' instruction in
crt0.s was linked to go to 'start' instead.

So, using this I was able to investigate the problem.  It seems
that the cause is the fact that the R_ARC_B22_PCREL reloc has been
incorrectly specified in the elf32-arc.c file.  There were two
problems.  The first was that its 'partial_inplace' field had been set
to false.  This meant that the addend for the reloc was not being
stored in the instruction.  Since the ARC uses REL format relocs and
not RELA format, this is a bad thing.  The other problem was that the
'pcrel_offset' field had been set to true, so the offset was being
calculated as if the address of the instruction had already been added
into the addend held in the instruction.  Again this was wrong.

Anyway after applying the patch below to fix these things I was able
to link my test executable and the disassembled dump appears to be
correct.

Please could you check to see if this patch works for you (and that it
works for real code, not just the little tests that I ran).  If it
does, please let me know and I will check the patch into the sources.

Cheers
        Nick

2001-08-02  Nick Clifton  <address@hidden>

        * elf32-arc.c (R_ARC_B22_PCREL): Change 'partial_inplace' to
        true (this target uses REL relocations) and 'pcrel_offset' to
        false (the PC is implied, not stored in the offset).

Index: bfd/elf32-arc.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-arc.c,v
retrieving revision 1.5
diff -p -r1.5 elf32-arc.c
*** elf32-arc.c 2001/05/12 15:14:53     1.5
--- elf32-arc.c 2001/08/02 10:56:17
*************** static reloc_howto_type elf_arc_howto_ta
*** 95,104 ****
         complain_overflow_signed, /* complain_on_overflow  */
         bfd_elf_generic_reloc, /* special_function  */
         "R_ARC_B22_PCREL",     /* name  */
!        false,                 /* partial_inplace  */
         0x07ffff80,            /* src_mask  */
         0x07ffff80,            /* dst_mask  */
!        true),                 /* pcrel_offset  */
  
  };
  
--- 95,104 ----
         complain_overflow_signed, /* complain_on_overflow  */
         bfd_elf_generic_reloc, /* special_function  */
         "R_ARC_B22_PCREL",     /* name  */
!        true,                  /* partial_inplace  */
         0x07ffff80,            /* src_mask  */
         0x07ffff80,            /* dst_mask  */
!        false),                /* pcrel_offset  */
  
  };

sample.tgz
Description: Binary data