From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 424373858C39; Tue, 7 Mar 2023 17:42:44 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 424373858C39 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1678210964; bh=yUKyFlu0lJmJkHvScYngRN3jukXb9QLXywPkOgPeHUU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=M0JyrCmwzZQmAjmxAZs6vWV3nqXRoQjZbWwa8U2pJ+1ufNK8r7U5FkzpLvM6x2D0P QGCFS7hhdjY0dc7EZXstwDs74sFaQiWwJBEsZeXHh1sOvh7BoP1f8gPc3MY5SNpnrL WFyqrxLO3REN6Jm5KdHkzs0243fOAcBxwEKzToRQ= From: "woodard at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug libgcc/109054] _Unwind_GetLanguageSpecificData should have protected visibility Date: Tue, 07 Mar 2023 17:42:43 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libgcc X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: woodard at redhat dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: 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://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D109054 --- Comment #3 from Ben Woodard --- Actually what we were hoping to achieve was not to substitute another versi= on of _Unwind_GetLanguageSpecificData for the one that is in libgcc_s.so but rather to make it so that that another implementation of the function could= n't replace the specialized one that is currently in libgcc_s.so The problem that I ran into was that a library that an application was using libzmq from zeromq had a dependency on libunwind. Because of the loading or= der, this libunwind was loaded before libgcc_s.so and so the dynamic loader found the _Unwind_GetLanguageSpecificData in libunwind before it looked in libgcc_s.so this broke C++ exception handling. What I was hoping could be done is that libgcc_s.so could be forced to ALWA= YS use its own version of _Unwind_GetLanguageSpecificData rather than one foun= d in another library like libunwind. Regarding: "Though, I wonder how can unwinding work properly even if we did that. Because e.g. libstdc++.so.6 (or libsupc++.a) C++ EH personality routine cal= ls various _Unwind_* APIs too, including _Unwind_GetLanguageSpecificData, _Unwind_GetGR, _Unwind_GetIP*, _Unwind_GetRegionStart, so if it gets some subset of those symbols from a different unwinder, it can't work correctly." I can authoritatively state that it doesn't work at least on RHEL8 on ppc64= le. Maybe making it "protected" visibility is the wrong solution. If there is a= way to make it so that libsupc++ or libstdc++'s C++ EH personality routine coul= d be made to only call its own routines rather than ones coming from a different library that would resolve the problem that we have run into. Is there anot= her way to make this happen since all these functions need to be used together = as a cohort and cannot be mixed and matched.=