Re: Calling __cxa_thread_atexit_impl directly, from C code

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

On 29/08/22 16:21, Florian Weimer wrote:
> * Adhemerval Zanella Netto:
> 
>> Although it seems to be used solely by C++ and the interface is generic enough
>> so any runtime/language might use it as well for any thread exit deallocation
>> cleanup, I am not sure it would be feasible to export or support calling it
>> from C code.
> 
> It's an exported symbol, and usually we treat those as part of the ABI.

Right, but the double underscore also notes this is an implementation specific
symbol similar to fortify ones (where although glibc is bounded to supported
them indefinitely, it might not call them for if fortify changes to a compiler
generated builtin for instance).

> 
>> The interface also have two annoying peculiarities where calling from C code
>> is not straightforward: 
>>
>>   1. Any memory failure aborts the process, which is far from ideal to a
>>      generic interface.
>>
>>   2. User need to correctly declare __dso_handle; using NULL (or any invalid
>>      value) will bound the to callback to main program (which is not correct
>>      if use within a shared library).
>>
>> So I think it would be better to provide a different interface.
> 
> We could add this:
> 
> static inline int
> thread_atexit (void (*__callback) (void *__data), void *__data)
> {
>   extern void *__dso_handle __attribute__ ((__visibility__ ("hidden")));
>   extern int __cxa_thread_atexit_impl (void (*__callback) (void *__data),
>                                         void *__caller);
>   return __cxa_thread_atexit_impl (__callback, __data, &__dso_handle);
> }
> 
> to <stdlib.h> with some approriate preprocessor conditionals.

Or make it similar to atexit and provide it with static-only-routines.
It would simplify the prototype and header definitions.

> 
> Maybe libgcc_s should do the error checking in its __cxa_thread_atexit
> function?  Then we could simply use the existing implementation in the
> function above, remove our abort, and defer the problem to the
> thread_atexit caller.

It would mean that libgcc_s would need to build and use the fallback
implementation in the case of failure, which is suboptimal (although not
sure it would be an improvement over abort on failure).  

But I also think for compat reasons we can't really change 
__cxa_thread_atexit_impl, since C++ constructors will be the ones responsible
to call __cxa_thread_atexit and afaik it assumes it can not fail (meaning
that any failure will be ignored).