Wrong symbol index generated in object file

Wrong symbol index generated in object file

[Nemanja Popov]

Hi all,

I'm using binutils port for DLX CPU (version 2.14 20030612).
There is a problem when assembling file in which are two code sections,
.text and another one e.g  .foo, and when function from one section calls
function from another section. When that file is assembled, wrong symbol
index is generated for the relocation related to the cross section call. For
every call of that kind, symbol index points to the name of the section
instead of called function from that section. This causes problem with
relocation calculation at linking time.

Here is the example of asm code::

.section .foo,"ax",@progbits
.align 2
.proc _foo_func_1
.global _foo_func_1
_foo_func_1:
 nop
.endproc _foo_func_1

align 2
.proc _foo_func_2
.global _foo_func_2
_foo_func_2:
 nop
.endproc _foo_func_2

.text
.align 2
.proc _text_func
.global _text func
_text_func:
 jal _foo_func_2                           ;  calling function from another
section (calling  _foo_func_2  from section .foo)
.endproc _text func


Objdump of assembled source is like this:
-----------------------------------------

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000004  00000000  00000000  00000034  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .data         00000000  00000000  00000000  00000038  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00000000  00000000  00000000  00000038  2**0
                  ALLOC
  3 .foo    00000008  00000000  00000000  00000038  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
SYMBOL TABLE:
00000000 l    d  .text  00000000
00000000 l    d  .data  00000000
00000000 l    d  .bss   00000000
00000000 l    d  .foo     00000000
00000000 g       .foo     00000000   _foo_func_1
00000004 g       .foo     00000000   _foo_func_2
00000000 g       .text  00000000 _text_func


Disassembly of section .text:

00000000 <_text_func>:
   0:   0c 00 00 00     jal     0x00000004
                                0: R_DLX_RELOC_26_PCREL  .foo       <--- you
can see here that symbol index from object

                              file points to the section name (.foo) instead
of called function name (_func2).

                              I've found in obj file that symbol index is 4
instead of 6 for this relocation.

Disassembly of section .data:

Disassembly of section .foo:

00000000 <_foo_func_1>:
   0:   54 00 00 00     nop

00000004 <_foo_func_2>:
   4:   54 00 00 00     nop


As you can see, symbol index which references to the necessary symbol
(_foo_func2) for this relocation is wrong. That causes wrong relocation
calculation at linking time.
Can you please tell me where to look in binutils code to find where symbol
index gets wrong value. Is that in DLX related part of code or that can be
bug in this version of .binutils

Thanks in advance and best regards,
Nemanja Popov

Re: Wrong symbol index generated in object file

[Alan Modra]

On Sat, Mar 11, 2006 at 02:49:38PM +0100, Nemanja Popov wrote:
> As you can see, symbol index which references to the necessary symbol
> (_foo_func2) for this relocation is wrong. That causes wrong relocation
> calculation at linking time.

You may have found a problem, but the fact that _foo_func2 is replaced
by the section symbol .foo in the reloc isn't wrong in itself.
Effectively, the assembler is generating code for "jal .foo+4" instead
of "jal _foo_func_2".  Since _foo_func_2 is equal to .foo+4 this should
be OK.

You might like to take a look at bfd/elf32-dlx.c.  I think much of this
file is bogus.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: Wrong symbol index generated in object file

[Nemanja Popov]

Problem was in gas/config/tc-dlx.c

bfd_boolean
md_dlx_fix_adjustable (fixP)
   fixS *fixP;
{
  /* We need the symbol name for the VTABLE entries.  */
  return (fixP->fx_r_type != BFD_RELOC_VTABLE_INHERIT
          && fixP->fx_r_type != BFD_RELOC_VTABLE_ENTRY
}

which is  

#define tc_fix_adjustable(FIX) md_dlx_fix_adjustable (FIX)

It was missing one line:

  return (fixP->fx_r_type != BFD_RELOC_VTABLE_INHERIT
          && fixP->fx_r_type != BFD_RELOC_VTABLE_ENTRY
          && fixP->fx_r_type != BFD_RELOC_DLX_JMP26); 


Regards,
Nemanja

----- Original Message ----- 
From: "Alan Modra" <amodra@bigpond.net.au>
To: "Nemanja Popov" <nemanja.popov@micronasnit.com>
Cc: <binutils@sourceware.org>
Sent: Wednesday, March 15, 2006 12:22 PM
Subject: Re: Wrong symbol index generated in object file


> On Sat, Mar 11, 2006 at 02:49:38PM +0100, Nemanja Popov wrote:
>> As you can see, symbol index which references to the necessary symbol
>> (_foo_func2) for this relocation is wrong. That causes wrong relocation
>> calculation at linking time.
> 
> You may have found a problem, but the fact that _foo_func2 is replaced
> by the section symbol .foo in the reloc isn't wrong in itself.
> Effectively, the assembler is generating code for "jal .foo+4" instead
> of "jal _foo_func_2".  Since _foo_func_2 is equal to .foo+4 this should
> be OK.
> 
> You might like to take a look at bfd/elf32-dlx.c.  I think much of this
> file is bogus.
> 
> -- 
> Alan Modra
> IBM OzLabs - Linux Technology Centre
> 
> 
> __________ NOD32 1.1443 (20060314) Information __________
> 
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
> 
>

Re: Wrong symbol index generated in object file

[Alan Modra]

On Wed, Mar 15, 2006 at 03:31:35PM +0100, Nemanja Popov wrote:
> Problem was in gas/config/tc-dlx.c
> 
> bfd_boolean
> md_dlx_fix_adjustable (fixP)
>   fixS *fixP;
> {
>  /* We need the symbol name for the VTABLE entries.  */
>  return (fixP->fx_r_type != BFD_RELOC_VTABLE_INHERIT
>          && fixP->fx_r_type != BFD_RELOC_VTABLE_ENTRY
> }
> 
> which is  
> 
> #define tc_fix_adjustable(FIX) md_dlx_fix_adjustable (FIX)
> 
> It was missing one line:
> 
>  return (fixP->fx_r_type != BFD_RELOC_VTABLE_INHERIT
>          && fixP->fx_r_type != BFD_RELOC_VTABLE_ENTRY
>          && fixP->fx_r_type != BFD_RELOC_DLX_JMP26); 

No, you are just working around the real bug(s).  When I glanced at
elf32-dlx.c I saw these problems:

- Reloc howto for RELOC_26_PCREL has wrong src and dest masks.

- Handling of lo/hi relocs in _bfd_dlx_elf_hi16_reloc and
  elf32_dlx_relocate16 is clueless.  Well, really, it's clueless to
  choose to use REL relocs instead of RELA when you need to handle
  hi16 relocs, because you can only store 16-bit addends.  So the
  hi16/lo16 relocs always need to be emitted in pairs and the hi16
  handler needs to rummage around to find its mate in order to
  build a full 32-bit addend, *or* you must restrict the addends
  to only 16 bits.  The latter choice virtually requires that you
  never reduce reloc syms to section syms, because ld -r will
  almost certainly overflow your 16-bit addend field.

- Using section alignment to calculate the next insn boundary is
  asking for trouble.  What if someone increases the alignment
  using .align?

- Comments don't match the code.

- The following weird attempt at sign extension

  vallo = insn & 0x03FFFFFF;

  if (vallo & 0x03000000)
    vallo = ~(vallo | 0xFC000000) + 1;

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre