public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* Dealing with broken ELF libraries
@ 1999-09-01 15:47 Jeffrey A Law
  1999-09-01 16:03 ` Ulrich Drepper
  1999-09-02  6:55 ` Ian Lance Taylor
  0 siblings, 2 replies; 6+ messages in thread
From: Jeffrey A Law @ 1999-09-01 15:47 UTC (permalink / raw)
  To: binutils; +Cc: drepper

Ho hum.  In typical fashion HP made some goof's in their ELF implementation
which apparently nobody's noticed because nobody else in their right mind is
writing ELF tools to work on hpux11 :-)

Can someone spot the bug in these two header dumps?

readelf -S libc.so 
There are 42 section headers, starting at offset 0x1227b8:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf 
Al
  [ 0]                   NULL            00000000 ffffffff 000000 00      0   
0 0
  [ 1] .dynamic          DYNAMIC         000011c8 0001c8 000150 10  A   0   0 8
  [ 2] .dynsym           DYNSYM          00001318 000318 00a050 18  A   3   0 8
  [ 3] .dynstr           STRTAB          0000b368 00a368 00482f 00  A   0   0 1

[ ... ]

[law@portal /scr/hp-elf-native/ld/test] readelf -S libdl.so
There are 35 section headers, starting at offset 0x51c8:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf 
Al
  [ 0]                   NULL            00000000 ffffffff 000000 00      0   
0 0
  [ 1] .dynamic          DYNAMIC         000011c8 0001c8 000120 10  A   0   0 8
  [ 2] .dynsym           DYNSYM          000012e8 0002e8 000360 18  A   3   0 8
  [ 3] .dynstr           STRTAB          00001648 000648 000203 00  A   0   0 1


Stumped?  The link for the .dynamic field points back to section #0 instead
of pointing to section #3.  Opps.

This causes gld/bfd some problems:

elflink.c::elf_link_add_object_symbols

      s = bfd_get_section_by_name (abfd, ".dynamic");
[ ... blah blah blah ... ]

          elfsec = _bfd_elf_section_from_bfd_section (abfd, s);
          if (elfsec == -1)
            goto error_return;
          link = elf_elfsections (abfd)[elfsec]->sh_link;

So we get a link of 0.  Of course section #0 is not a string table.  This
causes grief later when we do something like call
bfd_elf_string_from_elf_section.


So what do y'all think the best workaround might be?  Yes, I know HP should fix
their tools & libraries, but the libraries with the bogus link fields are
fairly widespread already.  And while HP may fix their tools, all the existing
sites lose if we can't find a good workaround.

We might be able to do something like recognize that LINK refers to a section
that is not of type STRTAB (and then fall back to looking for .dynsym's
string table).

Other options?

jeff

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Dealing with broken ELF libraries
  1999-09-01 15:47 Dealing with broken ELF libraries Jeffrey A Law
@ 1999-09-01 16:03 ` Ulrich Drepper
  1999-09-01 16:11   ` Jeffrey A Law
  1999-09-02  6:55 ` Ian Lance Taylor
  1 sibling, 1 reply; 6+ messages in thread
From: Ulrich Drepper @ 1999-09-01 16:03 UTC (permalink / raw)
  To: law; +Cc: binutils

Jeffrey A Law <law@cygnus.com> writes:

> We might be able to do something like recognize that LINK refers to a section
> that is not of type STRTAB (and then fall back to looking for .dynsym's
> string table).

Seems to be the most logical solution (and not to hard to implement).

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Dealing with broken ELF libraries
  1999-09-01 16:03 ` Ulrich Drepper
@ 1999-09-01 16:11   ` Jeffrey A Law
  1999-09-02  6:57     ` Ian Lance Taylor
  0 siblings, 1 reply; 6+ messages in thread
From: Jeffrey A Law @ 1999-09-01 16:11 UTC (permalink / raw)
  To: Ulrich Drepper; +Cc: binutils

  In message < m3u2peme50.fsf@localhost.localnet >you write:
  > Jeffrey A Law <law@cygnus.com> writes:
  > 
  > > We might be able to do something like recognize that LINK refers to a sec
  > tion
  > > that is not of type STRTAB (and then fall back to looking for .dynsym's
  > > string table).
  > 
  > Seems to be the most logical solution (and not to hard to implement).
That's what I'm using internally while I fart around with other stuff that
I'm going to need to perform dynamic linking.

It turns out that you can't do a pure static link on hpux11 -- too many things
missing from hp's libraries.  So we've got to make dynamic linking work from
day 1.  Ugh so much for building some quick code I can use to test basic
relocations. :(

jeff

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Dealing with broken ELF libraries
  1999-09-01 15:47 Dealing with broken ELF libraries Jeffrey A Law
  1999-09-01 16:03 ` Ulrich Drepper
@ 1999-09-02  6:55 ` Ian Lance Taylor
  1 sibling, 0 replies; 6+ messages in thread
From: Ian Lance Taylor @ 1999-09-02  6:55 UTC (permalink / raw)
  To: law; +Cc: binutils, drepper

   Date: Wed, 01 Sep 1999 16:36:59 -0600
   From: Jeffrey A Law <law@cygnus.com>

   We might be able to do something like recognize that LINK refers to a section
   that is not of type STRTAB (and then fall back to looking for .dynsym's
   string table).

I don't know what else would work.

Note that we already do workarounds like that in other cases.  For
example, the Oracle libraries on Solaris have a similar bug (or at
least they used to): the link field of the SHT_RELA sections does not
point to the appropriate symbol table.  You can see the workaround in
bfd_section_from_shdr in bfd/elf.c.

Ian

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Dealing with broken ELF libraries
  1999-09-01 16:11   ` Jeffrey A Law
@ 1999-09-02  6:57     ` Ian Lance Taylor
  1999-09-02  9:09       ` Ulrich Drepper
  0 siblings, 1 reply; 6+ messages in thread
From: Ian Lance Taylor @ 1999-09-02  6:57 UTC (permalink / raw)
  To: law; +Cc: drepper, binutils

   Date: Wed, 01 Sep 1999 17:02:11 -0600
   From: Jeffrey A Law <law@cygnus.com>

   It turns out that you can't do a pure static link on hpux11 -- too many things
   missing from hp's libraries.  So we've got to make dynamic linking work from
   day 1.  Ugh so much for building some quick code I can use to test basic
   relocations. :(

FYI, the same is true on typical Irix systems.  However, SGI ran their
SPECmark testing using static libraries, since they run faster.
Therefore, by the SPEC rules SGI had to supply the static libraries
they used, and they are enough to link simple programs.

I don't know if HP tried anything similar.

Ian

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Dealing with broken ELF libraries
  1999-09-02  6:57     ` Ian Lance Taylor
@ 1999-09-02  9:09       ` Ulrich Drepper
  0 siblings, 0 replies; 6+ messages in thread
From: Ulrich Drepper @ 1999-09-02  9:09 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: law, binutils

Ian Lance Taylor <ian@zembu.com> writes:

> I don't know if HP tried anything similar.

Probably not.  It's only MIPS where the difference between static and
dynamic binaries is so huge due to the mis-design of the lazy
relocation.  Beside, HP has acquired from Sun the NSS technology which
on traditional dynamic loading systems prohibits static linking.
(Only exception: glibc).

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~1999-09-02  9:09 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-09-01 15:47 Dealing with broken ELF libraries Jeffrey A Law
1999-09-01 16:03 ` Ulrich Drepper
1999-09-01 16:11   ` Jeffrey A Law
1999-09-02  6:57     ` Ian Lance Taylor
1999-09-02  9:09       ` Ulrich Drepper
1999-09-02  6:55 ` Ian Lance Taylor

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).