https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68606
--- Comment #3 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 30 Nov 2015, rdiezmail-gcc at yahoo dot de wrote: > 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. Yeah, but the whole issue is for being able to throw std::bad_alloc when no memory is available... > 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(). Unfortunately with C++11 and std::exception_ptr this became unmanagable. > 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. See above - with std::exception_ptr you can throw an EH in thread1, catch it and re-throw it from thread2... Of course at some point you have to say "oh well.." but the standard seems to not allow that. Like marking certain exceptions "non-addressable".
