Re: Handling __cxa_atexit(a,b,NULL)

[Joerg Sonnenberger <joerg%bec.de@localhost>]

On Thu, Nov 02, 2017 at 09:13:36PM +0100, Kamil Rytarowski wrote:
> On 02.11.2017 20:45, Joerg Sonnenberger wrote:
> > On Thu, Nov 02, 2017 at 07:09:34PM +0100, Kamil Rytarowski wrote:
> >> TSan intercepts all atexit() and __cxa_atexit() calls and wraps them in
> >> setup_at_exit_wrapper(() into a new struct that preserves the original
> >> arguments "a" and "b" from __cxa_atexit() / "a" from atexit(). In case
> >> of intercepting atexit() calls we end up with __cxa_atexit(x,y,NULL). In
> >> libc we handle this variation in the same way as atexit(x) and drop the
> >> "y" argument.
> > 
> > It should be intercepting atexit separately and just providing its own
> > stack, followed by registering a pop-and-call handler via the real
> > atexit, i.e.:
> > 
> >    std::vector<h> atexit_stack;
> >    void my_cleanup(void) {
> >      h = atexit_stack.pop();
> >      h();
> >    }
> > 
> >    int intercepted_atexit(h) {
> >      atexit_stack.push(h);
> >      rv = real_atexit(my_cleanup);
> >      if (rv) atexit_stack.pop();
> >      return rv;
> >    }
> > 
> > Joerg
> > 
> 
> Is this stack order deterministic? If so, I will go for it.

atexit handlers are called in reverse order. Nothing stops registering
the same handler more than once and this leaves the interleaving of
__cxa_atexit and atexit to the real implementation.

Joerg