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

["arek at hiler dot eu" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #8 from Arkadiusz Hiler <arek at hiler dot eu> ---
(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.

(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.

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