[cxx-abi-dev] Type mismatch in __cxa_atexit and __cxa_finalize
Matt Austern
austern at apple.com
Mon Mar 1 22:07:12 UTC 2004
On Feb 27, 2004, at 11:25 AM, Mark Mitchell wrote:
> Matt Austern wrote:
>
>> Maybe this is old news; I'm sure everyone who has implemented atexit
>> in terms of __cxa_atexit must have noticed it already.
>
> I believe that GNU libc implemented both atexit and __cxa_atexit atop
> some other interface, but I haven't looked in a long time.
>
>> The obvious fix would be to say that:
>> 1. atexit(f) invokes __cxa_atexit((void(*)(void*)) f, 0, 0).
>> 2. If you're passing __cxa_atexit a function that does take an
>> argument, the parameter may not be 0.
>> 3. When __cxa_finalize invokes a function f on a parameter p, it
>> should do the equivalent of:
>> if (p)
>> (*f)(p);
>> else
>> (*((void (*)(void)) f))();
>
> That's a reasonable approach, but point (2) worries me -- that might
> represent a change for some existing implementations.
>
> An alternative would be to remove the explicit impliciation in the ABI
> that atexit is implemented atop __cxa_atexit, and just indicate that
> (a) the calls to the registered functions must be interleaved in the
> appropriate way, and (b) __cxa_finalize called with a NULL DSO
> parameter must call the functions registered with atexit.
>
> Thoughts?
I'm mildly nervous about point (2) also, but only mildly. The number
of compilers that use this ABI isn't huge, and it shouldn't be hard to
confirm that there are no compilers that use a NULL data pointer. I
bet there are none. And we now know there is one implementation that
uses this technique. So this is my very-slightly-preferred option.
But then, I also don't mind your alternative. It's equally easy to
specify, and it's only slightly harder to implement.
--Matt
More information about the cxx-abi-dev
mailing list