[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 #11 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Arkadiusz Hiler from comment #10)
> (In reply to Adhemerval Zanella from comment #9)
> > 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.
> 
> ~16kB that's used by a whole class of games that are now unplayable on more
> bleeding-edge distros.
> 
> See: https://github.com/ValveSoftware/Proton/issues/6051
> 
> > 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).
> 
> Shifting responsibility on downstream to maintain compatibility with
> something
> that glibc provided for years as the default and there are now users of it
> is not really feasible.
> 
> I don't think I can convince you. I really hoped it can be just a simple
> revert.
> The best I can do is to report that a thing used to work is now broken and
> point to a commit that caused it.

In fact, we take backward compatibility quite seriously, the main issue here is
what characterizes an ABI break and what kind of forward compatibility and
extra internal details changes we need to take care of.

I am not against revert this change, but it really odd that on all system
binaries we need to keep the sysv hash solely for glibc add eternum because a
specific tool where we do not really understand exactly why requires such
functionality, and it does not provide any extra function to glibc itself.

Does it also prevent us to add another possible HASH scheme in the future,
taking that EAC might break if it does see a DT_GNU_HASH?

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