public inbox for libstdc++@gcc.gnu.org
 help / color / mirror / Atom feed
* libstdc++ "freestanding" ('--disable-hosted-libstdcxx') with '-fno-rtti', '-fno-exceptions': 'libstdc++-v3/libsupc++/eh_alloc.cc' global constructors
@ 2022-07-14 11:54 Thomas Schwinge
  2022-07-14 15:25 ` Jonathan Wakely
  0 siblings, 1 reply; 2+ messages in thread
From: Thomas Schwinge @ 2022-07-14 11:54 UTC (permalink / raw)
  To: libstdc++, Jonathan Wakely

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, and/or whether this
should be expected to compile fine already?  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?


Grüße
 Thomas
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: libstdc++ "freestanding" ('--disable-hosted-libstdcxx') with '-fno-rtti', '-fno-exceptions': 'libstdc++-v3/libsupc++/eh_alloc.cc' global constructors
  2022-07-14 11:54 libstdc++ "freestanding" ('--disable-hosted-libstdcxx') with '-fno-rtti', '-fno-exceptions': 'libstdc++-v3/libsupc++/eh_alloc.cc' global constructors Thomas Schwinge
@ 2022-07-14 15:25 ` Jonathan Wakely
  0 siblings, 0 replies; 2+ messages in thread
From: Jonathan Wakely @ 2022-07-14 15:25 UTC (permalink / raw)
  To: Thomas Schwinge; +Cc: libstdc++

[-- 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
   }
 }
 

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2022-07-14 15:25 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-14 11:54 libstdc++ "freestanding" ('--disable-hosted-libstdcxx') with '-fno-rtti', '-fno-exceptions': 'libstdc++-v3/libsupc++/eh_alloc.cc' global constructors Thomas Schwinge
2022-07-14 15:25 ` Jonathan Wakely

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).