Re: Wrong symbol index generated in object file

[Alan Modra <amodra at bigpond dot net dot au>]

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