From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C6EF8385701E; Mon, 8 Aug 2022 17:13:25 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C6EF8385701E 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 17:13:25 +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 17:13:25 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D29456 --- Comment #11 from Adhemerval Zanella --- (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.= =20 > >=20 > > On libc.so for x86_64, I see: > >=20 > > * with -Wl,--hash-style=3Dboth > > $ size libc.so > > text data bss dec hex filename > > 1992171 20320 55120 2067611 1f8c9b libc.so > >=20 > > * with -Wl,--hash-style=3Dgnu > > text data bss dec hex filename > > 1975923 20304 55120 2051347 1f4d13 libc.so > >=20 > > Roughly 1%, which is considerable for an unused feature. >=20 > ~16kB that's used by a whole class of games that are now unplayable on mo= re > bleeding-edge distros. >=20 > See: https://github.com/ValveSoftware/Proton/issues/6051 >=20 > > So it does not make much sense to enforce DT_HASH on libc.so, especiall= y if > > users do want to do symbol resolution it is still provided by DT_GNU_HA= SH. > > The glibc build now uses the default set by binutils, so maybe one opti= on is > > to enforce -Wl,--hash-style=3Dboth as distro level if this is really a > > compatibility issue (since it might not be specific to glibc shared obj= ects). >=20 > 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. >=20 > 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 her= e 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? --=20 You are receiving this mail because: You are on the CC list for the bug.=