From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C6BD9385735F; Mon, 8 Aug 2022 15:08:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C6BD9385735F From: "arek at hiler dot eu" To: glibc-bugs@sourceware.org Subject: [Bug build/29456] missing DT_HASH section in shared objects Date: Mon, 08 Aug 2022 15:08:32 +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: arek at hiler dot eu 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:08:32 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D29456 --- Comment #8 from Arkadiusz Hiler --- (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 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=3Dgnu` 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. --=20 You are receiving this mail because: You are on the CC list for the bug.=