[Bug libgcc/109054] _Unwind_GetLanguageSpecificData should have protected visibility

["woodard at redhat dot com" <gcc-bugzilla@gcc.gnu.org>]

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.