This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.

-- 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]