[Bug build/29456] missing DT_HASH section in shared objects

["adhemerval.zanella at linaro dot org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=29456

--- Comment #9 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Arkadiusz Hiler from comment #8)
> (In reply to Florian Weimer from comment #6)
> > > Do you know why distros do this?
> > 
> > sysv hashing is much slower for symbol binding because we have to do a
> > strcmp even on lookup failure. The Bloom filter is missing, too. Once the
> > glibc dynamic linker supported it, I think distributions really wanted to
> > use it, even if binutils and GCC defaults had not caught up at that point
> > yet. It fixes real issues around startup performance.
> 
> I've read through both algorithms and seen the benchmarks / original
> discussion around the new hash algorithm. The new one is unquestionably
> superior.
> 
> I don't understand why people forced "gnu" instead of "both" though.
> From my point of view, as an outsider, it looks like people hopped on the
> feature a bit early overriding upstream defaults and it has stuck.
> 
> If they would not have carried over `--with-linker-hash-style=gnu` from
> that era we would respect linker's default, which is both for The GNU
> Linker.
> 
> As far as I understand there's small size increase and no real performance
> penalty caused by having both.
> 
> This is mostly besides the point though and doesn't affect the perceived
> breakage, but I appreciate having the historical context.

It was done as size optimization from perceived unused features since
DT_GNU_HASH is being used as a default on most distros for a long time. 

On libc.so for x86_64, I see:

* with -Wl,--hash-style=both
$ size libc.so
   text    data     bss     dec     hex filename
1992171   20320   55120 2067611  1f8c9b libc.so

* with -Wl,--hash-style=gnu
   text    data     bss     dec     hex filename
1975923   20304   55120 2051347  1f4d13 libc.so

Roughly 1%, which is considerable for an unused feature.

> 
> (In reply to Adhemerval Zanella from comment #7)
> > Right, however, I am not sure this characterize as an ABI break since the
> > symbol lookup information would be indeed provided (albeit in a different
> > format). And it should be transparent to most applications as well since
> > symbol resolution is done by the loader itself.
> 
> The glibc loader is not the only thing that can do symbol resolution, and
> software that ships with distros is not the only software out there.
> Changing the section name and the format is significant. All the historical
> software that uses old version of dlsym() that's linked in to use pthreads
> would break.

But we do not really support loading two different C runtime environments (for
instance having libc.so with different versions in a different namespace), nor
loading libc.so by a different executable (for instance dlsym libc.so from a
different C runtime implementation), and static dlopen is being deprecated
(meaning that eventually, we will phase out its support, besides the already
know issues).

And dlopen libphtread will still work since we continue to provide a stub
libpthread.so.  Are you aware of an issue with the current scheme?

So it does not make much sense to enforce DT_HASH on libc.so, especially if
users do want to do symbol resolution it is still provided by DT_GNU_HASH. The
glibc build now uses the default set by binutils, so maybe one option is to
enforce -Wl,--hash-style=both as distro level if this is really a compatibility
issue (since it might not be specific to glibc shared objects).

-- 
You are receiving this mail because:
You are on the CC list for the bug.