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;