Re: ELF empty hash table: howto?

["Carmelo Amoroso" <carmelo73 at gmail dot com>]

On 26/09/2007, John Reiser <jreiser@bitwagon.com> wrote:
> > 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.
>
> --
>
Thanks a lot, it sound reasonable, especially when mixing SysV/GNU
hash table into
executable and DSOs.

Regards,
Carmelo