https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68606
--- Comment #2 from R. Diez <rdiezmail-gcc at yahoo dot de> --- A setting like LIBSTDCXX_EMERGENCY_EH_POOL_SIZE sounds good. However, an environment variable will not help me, it has to be a configuration option when building the toolchain. I am writing embedded firmware with newlib, and, as far as I know, there are no environment variables on start-up. You can set them in main() with setenv(), but that's too late, the emergency pool has already been initialised by then. I would also like to specify a size of 0 to disable it completely. I need to save as much memory as I can. After all, even if the emergency pool is huge, it can still happen that it is not enough, so the exception-handling code must already deal with that case that the pool has no room left, maybe with panic(). In my case, if there is no malloc() space available to throw an exception, the system is not working properly anyway. By the way, setting the size of some global emergency pool on start-up seems like a hack. You do not really know how big it should be, that depends for example on the number of threads you have, which is not known upfront. Reserving space per thread can help, but that's then a big waste if you have many threads. I suggest a special case in the unwind logic that can throw a particular out-of-memory exception like std::bad_alloc without allocating memory with malloc(). Whatever happened to the sensible way of allocating the exception on the stack and copying it up the stack every time the stack unwinds? I don't think that optimising the performance of the error-handling case is a high priority, at least for most applications. At least for embedded applications, allocating with malloc() when you throw is far worse. That prevents, for example, throwing in interrupt context, where malloc() is often not available.
