https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109054
--- Comment #3 from Ben Woodard <woodard at redhat dot com> --- Actually what we were hoping to achieve was not to substitute another version 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 couldn'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 order, 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 ALWAYS use its own version of _Unwind_GetLanguageSpecificData rather than one found 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 calls 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 ppc64le. 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 could 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 another way to make this happen since all these functions need to be used together as a cohort and cannot be mixed and matched.
