libstdc++ "freestanding" ('--disable-hosted-libstdcxx') with '-fno-rtti', '-fno-exceptions': 'libstdc++-v3/libsupc++/tinfo.cc'

[Jonathan Wakely]

On Thu, 14 Jul 2022 at 19:14, Thomas Schwinge <thomas@codesourcery.com> wrote:
>
> Hi!
>
> In context of <https://gcc.gnu.org/PR101544> '[OpenMP][AMDGCN][nvptx]
> C++ offloading: unresolved _Znwm = "operator new(unsigned long)"'
> I'm looking into building GCN, nvptx offloading libstdc++ "freestanding"
> ('--disable-hosted-libstdcxx') with '-fno-rtti', '-fno-exceptions'.
> (I've basically got these things wired up; details to be shared later.)
>
> While there is some experimental/incomplete/not-to-be-relied-on support
> for PTX symbol aliases, we're currently generally running into
> "error: alias definitions not supported in this configuration"
> for certain GCC/C++-front-end-generated code, for example:
> "complete object destructor" aliasing "base object destructor"
> (<https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling-special-ctor-dtor>
> -- per my understanding, at least).  ;-)
>
> It'll ultimately be possible to implement more complete symbol aliasing
> support for nvptx, but I found that this specific issue actually is due
> to a nvptx back end mis-configuration; fixed with adequate
> 'TARGET_USE_LOCAL_THUNK_ALIAS_P' and/or 'TARGET_SUPPORTS_ALIASES'
> definitions (details to be shared later).
>
> However, we then still run into:
>
>     [...]/libstdc++-v3/libsupc++/tinfo.cc:55:1: error: alias definitions not supported in this configuration
>        55 | std::type_info::__equal (const std::type_info& arg) const _GLIBCXX_NOEXCEPT
>           | ^~~
>     make[4]: *** [Makefile:777: tinfo.lo] Error 1
>
> That's 'libstdc++-v3/libsupc++/tinfo.cc':
>
>      1 // Methods for type_info for -*- C++ -*- Run Time Type Identification.
>     [...]
>     39 // We can't rely on common symbols being shared between shared objects.
>     40 bool std::type_info::
>     41 operator== (const std::type_info& arg) const _GLIBCXX_NOEXCEPT
>     42 {
>     43 #if __GXX_MERGED_TYPEINFO_NAMES
>     44   return name () == arg.name ();
>     45 #else
>     46   /* The name() method will strip any leading '*' prefix. Therefore
>     47      take care to look at __name rather than name() when looking for
>     48      the "pointer" prefix.  */
>     49   return (&arg == this)
>     50     || (__name[0] != '*' && (__builtin_strcmp (name (), arg.name ()) == 0));
>     51 #endif
>     52 }
>     53
>     54 bool
>     55 std::type_info::__equal (const std::type_info& arg) const _GLIBCXX_NOEXCEPT
>     56 __attribute__((alias("_ZNKSt9type_infoeqERKS_")));
>     57 #endif
>     [...]
>
> ..., so there's a manual alias from the line 55 function to the line 41
> function (if I got that right).

That's only there for backwards compatibility on ARM EABI and other
targets that don't define __GXX_TYPEINFO_EQUALITY_INLINE==1.

My suggestion would be to define that macro for the target.

>
> Now we may surely address that in some different way, but I do wonder if
> we need this whole file at all, given this is
> "Methods for type_info for -*- C++ -*- Run Time Type Identification",
> RTTI, and we're generally assuming '-fno-rtti'?  Do certain things simply
> need to be '#if'-conditionalized, or similar, for example?  I've not yet
> looked into the details; hoping that's maybe easy for you to answer?

Again, is -fno-rtti globally true for all code for this target? Not
just while building libstdc++?

If the answer is yes, then you don't need the symbols in this file.