bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/12339] New: Invalid .rel.plt section data is generated when a li


From: grassman at gmail dot com
Subject: [Bug ld/12339] New: Invalid .rel.plt section data is generated when a linked symbol is warning symbol (ELF32, ARM only)
Date: Wed, 22 Dec 2010 13:24:57 +0000

http://sourceware.org/bugzilla/show_bug.cgi?id=12339

           Summary: Invalid .rel.plt section data is generated when a
                    linked symbol is warning symbol (ELF32, ARM only)
           Product: binutils
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ld
        AssignedTo: address@hidden
        ReportedBy: address@hidden


A couple of days ago I found a program (dropbear - SSH server) generating
segfault. I examined that program and found .rel.plt section was broken.
After two days of bug tracking, I found the following bug and report it now.

When an elf32_arm_link_hash_entry is defined as bfd_link_hash_warning,
the first thing to do before accessing it is finding the hidden 'real'
entry. But 'allocate_dynrelocs' function does not. The variable 'eh'
is not referencing the 'real' entry. This results in an invalid
'eh->plt_got_offset' value (under my cross-compile environment).
After fixing this code, everything seems fine.

bfd/elf32-arm.c file
---------------------------------------------------------------------------

static bfd_boolean
allocate_dynrelocs (struct elf_link_hash_entry *h, void * inf)
{
  struct bfd_link_info *info;
  struct elf32_arm_link_hash_table *htab;
  struct elf32_arm_link_hash_entry *eh;
  struct elf_dyn_relocs *p;
  bfd_signed_vma thumb_refs;

  eh = (struct elf32_arm_link_hash_entry *) h;   /* <- THIS IS THE PROBLEM */

  if (h->root.type == bfd_link_hash_indirect)
    return TRUE;

  if (h->root.type == bfd_link_hash_warning)
    /* When warning symbols are created, they **replace** the "real"
       entry in the hash table, thus we never get to see the real
       symbol in a hash traversal.  So look at it now.  */
    h = (struct elf_link_hash_entry *) h->root.u.i.link;

  // <- PLEASE MOVE THE ABOVE LINE HERE

---------------------------------------------------------------------------

In addition to above problem, ld doesn't list warning symbols in the map file.
Is it intended? If not, please add the following two lines to the beginning of
'sort_def_symbol' function (ld/ldlang.c file).

  if (hash_entry->type == bfd_link_hash_warning)
    hash_entry = (struct bfd_link_hash_entry *) hash_entry->u.i.link;

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.



reply via email to

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