[patch] libstdc++/69945 Add __gnu_cxx::__freeres hook

[Jonathan Wakely]

On 25/02/16 10:36 +0100, Richard Biener wrote:
>On Wed, Feb 24, 2016 at 7:35 PM, Jonathan Wakely <jwakely@redhat.com> wrote:
>> This adds a new function to libsupc++ which will free the memory still
>> in use by the pool used for allocating exceptions when malloc fails.
>>
>> This is similar to glibc's __libc_freeres, which valgrind (and other
>> tools?) use to tell glibc to deallocate everything before exiting.
>>
>> I initially called it __gnu_cxx::__free_eh_pool() but I figured we
>> might have other memory in use at some later date, and we wouldn't
>> want valgrind to have to start calling a second function, nor make a
>> function called __free_eh_pool() actually free other things.
>>
>> I intentionally *didn't* lock the pool's mutex before freeing it,
>> because this should never be called in a context where multiple
>> threads are still active and accessing the pool.
>>
>> Thoughts?
>>
>> Is the new test a good idea, or will exposing it like that in the
>> testsuite just give users the idea that they can/should be doing the
>> same themselves?
>
>The goal is to lookup the function via dlsym and only call it before
>glibcs freeres (which will probably make free() in-operatable?)

Yes, I believe so (Mark? Ivo?)

Another way to test it would be to use dg-final to run gdb in the
global's destructor and try to call the function from GDB.

>>
>> [ Aside: should the actual pool be created with placement-new to
>> [ ensure it doesn't ever get destroyed?
>> [
>> [   alignas(pool) unsigned char poolbuf[sizeof(pool)];
>> [   pool& emergency_pool = *::new(poolbuf) pool;
>
>Hmm, for pedantic correctness yes I guess.  But it hasn't any destructor,
>it's global (so no CLOBBER / memory re-use issue) and so the destruction
>won't do anything.  Of course it might simply save a global dtor (does it
>even register one?  I don't see one).

It was the CLOBBER that I was thinking about, but I agree we don't
(currently) do that for trivial destructors.

>There is still the missing feature of allowing to size the emergency
>pool using an environment variable (properly securely implemented, of course).

Yes.