* 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).