|
From: Gu R. <ru...@gm...> - 2015-09-09 19:50:49
|
Dear Valgrind Developers:
My name is Rui Gu, a student from Columbia University. Thanks for building and maintaining such great tool!
Right now, we’re trying to enable Helgrind on UserModeLinux(UML).
We’ve encountered a problem and want to get a clue about the best way of solving it.
Let me put our basic understanding of Valgrind and the problems we encountered here.
Helgrind:
For a thread that is created by pthread_create(). Valgrind first intercept pthread_create() in hg_intercept.c for some threading info registration. Then, coregrind will intercept clone() in syswrap-x86-linux.c to monitor and control the thread creation and execution. Valgrind also supports some self-implemented synchronization primitives by using ANNOTATION.
Question:
In short, we want to ask what’s the most legitimate way of supporting user level thread scheduling system?
The detailed question goes from here:
The problem is that UML will have its own user level threading systems. They use kernel_thread() to create threads and scheduling them on the user level.
The code is like this.
int kernel_thread(int (*fn)(void* ), void * arg, unsigned long flags)
{
int pid;
current->thread.request.u.thread.proc = fn;
current->thread.request.u.thread.arg = arg;
pid = do_fork(CLONE_VM | CLONE_UNTRACED | flags, 0,
¤t->thread.regs, 0, NULL, NULL);
return pid;
}
So, our guess is, in order to let Valgrind detect, monitor and control these threads. We need to first intercept kernel_thread() in hg_intercept.c and then intercept do_fork() in coregrind. Instead of letting coregrind calls clone internally, we’ll have to let Valgrind call do_fork() of UML.
The problem is right now, it’s kind of hard and strange to let coregrind to call a function within UML. Because coregrind is not supposed to see any guest program APIs and thus there isn’t any related API of doing it. So we’re wondering r we doing it in the right way?
Thanks in advance for your kind support.
Rui |