[PATCH] D20913: [asan] add primitives that allow coroutine implementations

[Filipe Cabecinhas via llvm-commits]

filcab added a comment.

In http://reviews.llvm.org/D20913#453199, @blastrock wrote:

> In http://reviews.llvm.org/D20913#452184, @filcab wrote:
>
> > My understanding is that we're calling `__sanitizer_*_enter_fiber` on an anything->fiber transition (be it the first one into that fiber or any other), and calling `__sanitizer_*_exit_fiber` on the *last* (for a given fiber) fiber->anything transition.
> >  Let me know if that's not the case. And if it's not, why it's not generalized like that.
>
>
> No, the second part is not exact (or I'm misunderstanding you). __sanitizer_*_exit_fiber are used when returning from the fiber to the thread's stack. The fiber may be re-entered later.
>  To be clear:
>
> - you call enter_fiber when you are about to switch to a fiber
> - you call exit_fiber when you are about to switch back to the thread's stack These are not related to the fiber's lifetime.


Do we need to care that we're doing a Fiber->Thread, though? Does it need to be handled differently, in general?

The way I see it, you could do something like (I'm giving vars/functions/members totally different names to avoid ambiguity with the current names. Feel free to keep something closer to your current ones):
`__sanitizer_fiber_switch_start(void *ctx, uptr size);`
This function is passed the fiber's or the thread's stack bounds, and sets `next_stack_{top,bottom}`.

`__sanitizer_fiber_switch_finish();`
This function is run in the new stack that you switched to and removes the current `stack_{top,bottom}`, replacing with what was in `next_stack_{top,bottom}` (setting the latter ones to `0`, after).

That way, you only have one primitive to deal with (This follows from our simple fiber implementation. Yours might have functionality that requires the current implementation. Please let me know).

The `FakeStack`s might be more annoying and require the fiber implementation to provide an easy way for us to store a random pointer-sized object. I don't think that should be a problem.

Do we want to keep track of fibers in the same way we keep track of threads, and be able to diagnose which fiber we were in on allocation/deallocation?
(I guess the answer might be "yes", but I mention this as a "future work" thing. We should try to take it into account, but shouldn't add it to this patch (or complicate it too much)).

> > As for the stack bounds: Would it be a problem to figure them out dinamycally in `__sanitizer_finish_enter_fiber`? Possibly with a callback from the fiber library, since we need to know if a fiber is running (Our system's fiber library has a function that queries TLS and tells you if you're running in a fiber. I have no idea about other implementations).

> 

> 

> I'm not sure I understand. You want to avoid giving the stack bounds as arguments to __sanitizer_start_enter_fiber? We actually need to know the stack bounds we are switching to beforehand, in case a signal handler runs on the fiber, before `__sanitizer_finish_enter_fiber` is called.


Fair enough. The signal handler case is interesting and I think it's worth it to get the bounds ahead because of it.


http://reviews.llvm.org/D20913