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