|
From: Philippe W. <phi...@sk...> - 2015-09-10 20:57:22
|
On Wed, 2015-09-09 at 15:50 -0400, Gu Rui wrote:
> 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?
How UML is working is not very clear to me.
Inside UML, when a 'guest' process is forking, does that create a new
'host' process ? Similarly, if a guest thread starts a new thread,
does that create a new 'host' thread ? And is all that based on
pthread primitives ?
Or alternatively, is everything simulated by UML, in one single host
process ?
(I suspect it is this last case).
If really there is only one single host process, in which the guest
kernel runs and 'simulates' guest processes/threads, then
I think some non trivial changes are needed to have helgrind working
on these simulated threads.
E.g. helgrind intercepts a whole bunch of pthread functions.
You will have to intercept the somewhat equivalent UML functions
so that helgrind is aware of the guest processes/guest threads.
helgrind also replaces the malloc/free/... functions.
Again, if you want helgrind to find relevant races, the
equivalent functions in UML will have to be replaced.
Sorry for not being able to clarify much (missing UML knowledge).
Philippe
|