* 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
