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

Philippe Daouadi via llvm-commits llvm-commits at lists.llvm.org
Fri Jun 3 05:57:34 PDT 2016


blastrock added a comment.

> If we express the annotations as start_switch/fnish_switch, then we have more flexibility to handle it. First, we can handle signal masks internally. Second, we can remember both old and new stacks for the duration of the switch, and then check both in __asan_handle_no_return. This will eliminate the need to mess with signal masks.


Oh, I see!

But I note that AsanThread::stack_*() functions are called by other functions than __asan_handle_no_return. I see one particular call in asan_thread.cc, in GetThreadRangesLocked(), it is done on the thread whose id is given as an argument. If that thread is in the middle of start_switch/finish_switch, I don't know which stack to return in AsanThread::stack_*().

I just noticed that I also forgot to change AsanThread::AddrIsInStack(), should it just return true if the address is in one of the two stacks when the thread is in the middle of a context switch? Would it have bad consequences?

Is there a way from an AsanThread to get its stack pointer? It would help to know if the thread is on one stack or the other for all usages of stack_*() and solve all these problems.

Or if the only problematic function is __asan_handle_no_return, I may have to handle the coroutine special case only there?


http://reviews.llvm.org/D20913





More information about the llvm-commits mailing list