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

[Jonathan Wakely <jwakely@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2168 bytes --]

On Thu, 14 Jul 2022 at 15:53, Thomas Schwinge 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.)
>
> For nvptx, I'm running into:
>
>     In function ‘(static initializers for [...]/libstdc++-v3/libsupc++/eh_alloc.cc)’:
>     cc1plus: sorry, unimplemented: global constructors not supported on this target
>     make[4]: *** [Makefile:777: eh_alloc.lo] Error 1
>
> ... because, indeed, "global constructors not supported" for nvptx at
> this time.  This may change, but I'd first like to get clarified
> conceptually to which extent 'libstdc++-v3/libsupc++/eh_alloc.cc' is
> actually relevant for such a libstdc++ configuration,


It depends.

Does your target *ever* support exceptions? Building libstdc++ with
-fno-exceptions means that the library code can't throw or catch
exceptions, but in theory user code linking to that libstdc++ build
could still be compiled with -fexceptions. In such a scenario, the
__cxxabiv1::__cxa_allocate_exception and
__cxxabiv1::__cxa_free_exception functions (which are required by the
C++ ABI) are still needed.

But if your target completely disallows -fexceptions, you probably
don't need anything in that file.


> and/or whether this
> should be expected to compile fine already?

I think a few people have built libstdc++ with -fno-rtti and
-fno-exceptions recently, and that should work. The problem here is
the lack of global ctors, which is much less common. You might find
other parts of libstdc++ that don't build for the same reason,
although maybe those other parts are all disabled for freestanding
builds.

>  Do certain things simply
> need to be '#if'-conditionalized, or similar, for example?

Yes, I think so.

> I've not yet
> looked into the details; hoping that's maybe easy for you to answer?

Does the attached patch work?

[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 980 bytes --]

diff --git a/libstdc++-v3/libsupc++/eh_alloc.cc b/libstdc++-v3/libsupc++/eh_alloc.cc
index c85b9aed40b..4060c9edf2e 100644
--- a/libstdc++-v3/libsupc++/eh_alloc.cc
+++ b/libstdc++-v3/libsupc++/eh_alloc.cc
@@ -80,6 +80,17 @@ namespace __gnu_cxx
 
 namespace
 {
+#define NO_EH_ALLOC_POOL
+#ifdef NO_EH_ALLOC_POOL
+  struct pool
+  {
+    static constexpr void* const arena = nullptr;
+
+    static void *allocate (std::size_t) { return nullptr; }
+    static void free (void *) { }
+    static bool in_pool (void *) { return false; }
+  };
+#else
   // A fixed-size heap, variable size object allocator
   class pool
     {
@@ -258,6 +269,7 @@ namespace
       return (p > arena
 	      && p < arena + arena_size);
     }
+#endif
 
   pool emergency_pool;
 }
@@ -267,11 +279,13 @@ namespace __gnu_cxx
   void
   __freeres()
   {
+#ifndef NO_EH_ALLOC_POOL
     if (emergency_pool.arena)
       {
 	::free(emergency_pool.arena);
 	emergency_pool.arena = 0;
       }
+#endif
   }
 }