Counting static __cxa_atexit calls

[Florian Weimer]

* Michael Matz:

> Hello,
>
> On Tue, 23 Aug 2022, Florian Weimer via Gcc wrote:
>
>> We currently have a latent bug in glibc where C++ constructor calls can
>> fail if they have static or thread storage duration and a non-trivial
>> destructor.  The reason is that __cxa_atexit (and
>> __cxa_thread_atexit_impl) may have to allocate memory.  We can avoid
>> that if we know how many such static calls exist in an object (for C++,
>> the compiler will never emit these calls repeatedly in a loop).  Then we
>> can allocate the resources beforehand, either during process and thread
>> start, or when dlopen is called and new objects are loaded.
>
> Isn't this merely moving the failure point from exception-at-ctor to 
> dlopen-fails?

Yes, and that is a soft error that can be handled (likewise for
pthread_create).

> If an individual __cxa_atexit can't allocate memory anymore for its
> list structure, why should pre-allocation (which is still dynamic,
> based on the number of actual atexit calls) have any more luck?

We can report the error properly, and not just terminate the process.

The existing ABI functions are mostly noexcept.  For C++ constructors of
global objects, there cannot even be a handler because they are invoked
by an ELF constructor, and throwing through an ELF constructor is
undefined.

>> What would be the most ELF-flavored way to implement this?  After the
>> final link, I expect that the count (or counts, we need a separate
>> counter for thread-local storage) would show up under a new dynamic tag
>> in the dynamic segment.  This is actually a very good fit because older
>> loaders will just ignore it.  But the question remains what GCC should
>> emit into assembler & object files, so that the link editor can compute
>> the total count from that.
>
> Probably a note section, which the link editor could either transform into 
> a dynamic tag or leave as note(s) in the PT_NOTE segment.  The latter 
> wouldn't require any specific tooling support in the link editor.  But the 
> consumer would have to iterate through all the notes to add the 
> individual counts together.  Might be acceptable, though.

I think we need some level of link editor support to avoid drastically
over-counting multiple static calls that get merged into one
implementation as the result of vague linkage.  Not sure how to express
that at the ELF level?

Thanks,
Florian