From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D7DA33857363; Mon, 8 Aug 2022 15:29:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D7DA33857363 From: "adhemerval.zanella at linaro dot org" To: glibc-bugs@sourceware.org Subject: [Bug build/29456] missing DT_HASH section in shared objects Date: Mon, 08 Aug 2022 15:29:29 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: build X-Bugzilla-Version: 2.36 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: adhemerval.zanella at linaro dot org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2022 15:29:30 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D29456 --- Comment #9 from Adhemerval Zanella --- (In reply to Arkadiusz Hiler from comment #8) > (In reply to Florian Weimer from comment #6) > > > Do you know why distros do this? > >=20 > > 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 t= he > > 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 poi= nt > > yet. It fixes real issues around startup performance. >=20 > I've read through both algorithms and seen the benchmarks / original > discussion around the new hash algorithm. The new one is unquestionably > superior. >=20 > 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. >=20 > If they would not have carried over `--with-linker-hash-style=3Dgnu` from > that era we would respect linker's default, which is both for The GNU > Linker. >=20 > As far as I understand there's small size increase and no real performance > penalty caused by having both. >=20 > 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.=20 On libc.so for x86_64, I see: * with -Wl,--hash-style=3Dboth $ size libc.so text data bss dec hex filename 1992171 20320 55120 2067611 1f8c9b libc.so * with -Wl,--hash-style=3Dgnu text data bss dec hex filename 1975923 20304 55120 2051347 1f4d13 libc.so Roughly 1%, which is considerable for an unused feature. >=20 > (In reply to Adhemerval Zanella from comment #7) > > Right, however, I am not sure this characterize as an ABI break since t= he > > symbol lookup information would be indeed provided (albeit in a differe= nt > > format). And it should be transparent to most applications as well since > > symbol resolution is done by the loader itself. >=20 > 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 historic= al > 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=3Dboth as distro level if this is really a compati= bility issue (since it might not be specific to glibc shared objects). --=20 You are receiving this mail because: You are on the CC list for the bug.=