ELF empty hash table: howto?
John Reiser
jreiser@BitWagon.com
Wed Sep 26 14:40:00 GMT 2007
> 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.
--
More information about the Libc-alpha
mailing list