This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
ELF empty hash table: howto?
- From: John Reiser <jreiser at BitWagon dot com>
- To: libc-alpha at sourceware dot org
- Date: Wed, 26 Sep 2007 07:40:14 -0700
- Subject: ELF empty hash table: howto?
> I'm just wondering how could happen having into an elf binary and
> empty hash table (sysv or gnu style doesn't care).
> /* If the hash table is empty there is nothing to do here. */
> if (map->l_nbuckets == 0)
> continue;
>
> Is there a case in which the binutils could create an empty hash
> table, so this check?
Binutils can do anything, and sometimes does. A main program with no
symbols visible to shared libraries is also a possibility. DT_GNU_HASH
increases the chances for an empty hash table, because the new convention
is that the table contains only visible defined symbols. Although not
required, in practice an old DT_HASH table also contained undefined symbols.
Restricting the hash table to defined symbols speeds runtime lookups
because the absence of a usable definition is detected sooner, so the
search can start looking in the next module sooner.
More importantly, there is a compatability glitch between DT_HASH
and DT_GNU_HASH. A module created with DT_GNU_HASH only, and no DT_HASH,
causes a SIGFPE when run under glibc-2.3.6. The 1.5-year old glibc
did not check for (.l_nbuckets == 0) yet performed a remainder operation
'%' anyway. This happened to me when running 'tracepath' from Fedora 8
test releases on an old system. There was no DT_HASH, so there was nothing
to set .l_nbuckets. Such cases of changing global assumptions (DT_HASH
vs DT_GNU_HASH) make it a good coding practice to check all divisors for 0.
--