Re: Counting static __cxa_atexit calls

[Florian Weimer <fweimer@redhat.com>]

* Michael Matz:

> Hello,
>
> On Wed, 24 Aug 2022, Florian Weimer wrote:
>
>> > 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).
>
> Makes sense.  Though that actually hints at a design problem with ELF 
> static ctors/dtors: they should be able to soft-fail (leading to dlopen or 
> pthread_create error returns).  So, maybe the _best_ way to deal with this 
> is to extend the definition of the various object-initionalization means 
> in ELF to allow propagating failure.

We could enable unwinding through the dynamic linker perhaps.  But as I
said, those Itanium ABI functions tend to be noexcept, so there's work
on that front as well.

For thread-local storage, it's even more difficult because any first
access can throw even if the constructor is noexcept.

>> > 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?
>
> Hmm.  The __cxa_atexit calls are coming from the per-file local static 
> initialization_and_destruction routine which doesn't have vague linkage, 
> so its contribution to the overall number of cxa_atexit calls doesn't 
> change from .o to final-exe.  Can you show an example of what you're 
> worried about?

Sorry if I didn't use the correct terminology.

I was thinking about this:

#include <vector>

template <int i>
struct S {
  static std::vector<int *> vec;
};

template <int i> std::vector<int *> S<i>::vec(i);

std::vector<int *> &
f()
{
  return S<1009>::vec;
}

The initialization is deduplicated with the help of a guard variable,
and that also bounds to number of __cxa_atexit invocations to at most
one per type.

> A completely different way would be to not use cxa_atexit at all: allocate 
> memory statically for the object and dtor addresses in .rodata (instead of 
> in .text right now), and iterate over those at static_destruction time.  
> (For the thread-local ones it would need to store arguments to 
> __tls_get_addr).

That only works if the compiler and linker can figure out the
construction order.  In general, that is not possible, and that case
seems even quite common with C++.  If the construction order is not
known ahead of time, it is necessary to record it somewhere, so that
destruction can happen in reverse.  So I think storing things in .rodata
is out.

Thanks,
Florian