bug-binutils
[Top][All Lists]
Advanced

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

[Bug binutils/15835] New: binutils can't deal with more than one SHT_SYM


From: richlowe at richlowe dot net
Subject: [Bug binutils/15835] New: binutils can't deal with more than one SHT_SYMTAB_SHNDX section (such as from Solaris or illumos link editor)
Date: Tue, 13 Aug 2013 17:59:47 +0000

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

            Bug ID: 15835
           Summary: binutils can't deal with more than one
                    SHT_SYMTAB_SHNDX section (such as from Solaris or
                    illumos link editor)
           Product: binutils
           Version: 2.23
            Status: NEW
          Severity: normal
          Priority: P2
         Component: binutils
          Assignee: unassigned at sourceware dot org
          Reporter: richlowe at richlowe dot net

in `bfd_section_from_shdr', in the case for SHT_SYMTAB_SHNDX
there's an assumption (and BFD_ASSERT to back it up)
that there will only be one section of that type per file.  With
dynamic objects created by the Solaris or illumos link editors,
there will generally be 3 such sections, one each for .symtab,
.dynsym and .SUNW_ldynsym.  This causes the code in question to
fail utterly, and seemingly destroy the object (in the binutils
I'm using, BFD_ASSERT seems to be little more than printf, no
abort or exit).

I have a libxul.so with 130,000 sections, when attempting to
modify it to test some changes to our toolchain, I did:

  $ binutils/objcopy --add-section .SUNW_ctf=foo.ctf ../libxul.so libxul-new.so
  BFD: BFD (GNU Binutils) 2.23.2 assertion fail elf.c:1714
  BFD: BFD (GNU Binutils) 2.23.2 assertion fail elf.c:1714

(these are the assertions regarding there not already being a symtab shndx
section)

The resulting libxul-new.so is, as you'd expect, trash:
   $ elfdump libxul-new.so 2>&1 >/dev/null | head
   libxul-new.so: .SUNW_ldynsym: invalid sh_link: 0
   libxul-new.so: .dynsym: index[1]: invalid SHN_XINDEX reference:
SHT_SYMTAB_SHNDX section not found
   libxul-new.so: .dynsym: index[4]: invalid SHN_XINDEX reference:
SHT_SYMTAB_SHNDX section not found
   libxul-new.so: .dynsym: index[8]: invalid SHN_XINDEX reference:
SHT_SYMTAB_SHNDX section not found
   libxul-new.so: .dynsym: index[11]: invalid SHN_XINDEX reference:
SHT_SYMTAB_SHNDX section not found
   libxul-new.so: .dynsym: index[12]: invalid SHN_XINDEX reference:
SHT_SYMTAB_SHNDX section not found
   libxul-new.so: .dynsym: index[13]: invalid SHN_XINDEX reference:
SHT_SYMTAB_SHNDX section not found
   libxul-new.so: .dynsym: index[14]: invalid SHN_XINDEX reference:
SHT_SYMTAB_SHNDX section not found
   libxul-new.so: .dynsym: index[17]: invalid SHN_XINDEX reference:
SHT_SYMTAB_SHNDX section not found
   libxul-new.so: .dynsym: index[24]: invalid SHN_XINDEX reference:
SHT_SYMTAB_SHNDX section not found
   ...
(there are many, many similar such complaints)

A simple test could be constructed using gcc's -ffunction-sections and
-fdata-sections and sufficient symbols to trigger extended section indexing.

-- 
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]