[Bug libgcc/109054] New: _Unwind_GetLanguageSpecificData should have protected visibility

[Bug libgcc/109054] New: _Unwind_GetLanguageSpecificData should have protected visibility

[woodard at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109054

            Bug ID: 109054
           Summary: _Unwind_GetLanguageSpecificData should have protected
                    visibility
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libgcc
          Assignee: unassigned at gcc dot gnu.org
          Reporter: woodard at redhat dot com
  Target Milestone: ---

When you look at libgcc_s.so's implementation of
_Unwind_GetLanguageSpecificData

$ eu-readelf -s /lib64/libgcc_s.so.1 | grep _Unwind_GetLanguageSpecificData
   67: 0000000000014d20     12 FUNC    GLOBAL DEFAULT       14
_Unwind_GetLanguageSpecificData@@GCC_3.0

It has default visibility. Yes I know that a library should not export
functions that are _[A-Z] because those are reserved for system libraries. ref:
http://eel.is/c++draft/lex.name#3.1 

However, libunwind does and this led to a very hard to track down problem when
they had linked an application a particular way. What happened was libgcc_s.so
picked up libunwind's implementation of _Unwind_GetLanguageSpecificData this
ultimately caused libgcc_s.so to not be able to find the LSDA of an object
throwing an exception. This made it so that there was no way to catch the
exception and therefore the application aborted. The application was not even
aware of the fact that they were using libunwind becasue it came in as a
dependency of libzmq.

I can't think of a good reason why libgcc_s.so should allow another library to
replace its version of _Unwind_GetLanguageSpecificData and so it seems to me
that the symbol's visibility should be made protected rather than having the
default visibility. 

Other related bugs are: https://bugzilla.redhat.com/show_bug.cgi?id=2175966

[Bug libgcc/109054] _Unwind_GetLanguageSpecificData should have protected visibility

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109054

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Protected visibility is always wrong, it is broken by design (or lack thereof).
The _Unwind_* APIs are required by the Itanium ABI, and we call various other
such functions from libgcc code already (e.g. _Unwind_Find_FDE from
_Unwind_FindEnclosingFunction and uw_frame_state_for and others,
_Unwind_GetTextRelBase, _Unwind_GetRegionStart,
_Unwind_GetDataRelBase, _Unwind_SetGR, _Unwind_SetIP, _Unwind_GetIPInfo and
_Unwind_GetCFA from various spots, _Unwind_RaiseException from
_Unwind_Resume_or_Rethrow
etc.).
It is IMHO very bad idea to have 2 different unwinders in the same process with
the same exported functions.
If you'd like libgcc to call local aliases of these functions instead of those
functions, I'm afraid it could break various things, e.g. i?86 glibc exports
_Unwind_Find_FDE too and we rely on a single registry for all unwinding.

[Bug libgcc/109054] _Unwind_GetLanguageSpecificData should have protected visibility

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109054

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fw at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
On the other side, it is true that the unwind-dw2{,_s}.o entrypoints (or at
least their majority) uses struct _Unwind_Context which is implementation
specific and so using some other one is likely incorrect (in theory one could
wrap it around and just use dlsym (RTLD_NEXT, "_Unwind_*") found entrypoints
under the hood with some extra code).
Things are even more complicated by libgcc being configurable to use libunwind
and just call __libunwind_* APIs under the hood (on by default only on
ia64-hpux but there is configure option for it elsewhere).
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.

[Bug libgcc/109054] _Unwind_GetLanguageSpecificData should have protected visibility

[woodard at redhat dot com]

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.

[Bug libgcc/109054] _Unwind_GetLanguageSpecificData should have protected visibility

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109054

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
As I tried to explain, because libgcc_s and libstdc++ are different libraries,
there is nothing that can be done on the GCC side.
You can avoid libunwind (which is a good idea, it is a terrible library from my
past experience with it), or if you can't, make sure libgcc comes earlier in
the search path, or that libunwind defines all the unwinder symbols (_Unwind_*)
and not just a subset (so whole app uses one unwinder or another depending on
search path, but not a mix of them).

[Bug libgcc/109054] _Unwind_GetLanguageSpecificData should have protected visibility

[woodard at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109054

Ben Woodard <woodard at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #5 from Ben Woodard <woodard at redhat dot com> ---
good enough