|
From: Josef W. <Jos...@gm...> - 2006-09-20 23:35:53
|
On Thursday 21 September 2006 01:14, Julian Seward wrote:
>
> > __NR_fork is defined somewhere in coregrind/, but I can not include it from
> > there. Using "#include <sys/syscall.h>" works however. I hope this is fine
> > from a VG tool.
>
> Urk, I prefer not.
>
> I plan shortly to merge into the trunk, some structural changes, one
> of which would properly move all the kernel interface stuff into a
> standard module 'vki' (so we would have pub_{core,tool}_vki.h) and
> all the syscall numbers into another module 'vkiscnums', so you
> would have pub_{core,tool}_vkiscnums.h. So then you could #include
> pub_tool_vkiscnums.h to get __NR_fork.
>
> This won't happen in the 3.2 branch though. I am happy to push your
> fix r6082 into 3.2.2,
Good. If someone wants to clear costs after fork, there is a workaround:
it is always possible to do a client request (CALLGRIND_ZERO_STATS) in
the code directly after fork in the child. This will miss a few instructions,
but that should be neglectable for profiling.
> but I think a complete solution to the fork
> will have to be in 3.3.X.
Fine with me. I'll keep the bug open.
> > > I'm sure the PRE(sys_clone) functions have some magic stuff
> > > to handle this.
> >
> > Not sure what to do here.
> > I can check for __NR_clone, but how to get the clone flags parameter in
> > the wrapper?
>
> I'm not sure that the scheme of having the tool inspect syscalls
> to detect fork() is going to work cleanly. This is because different
> platforms use different syscalls to do fork, eg Linux does sys_fork
> and sometimes sys_clone, but AIX only does sys_fork, and we don't
> want to force tools to have platform-specific handling like that.
>
> Maybe a better solution is to add to the core-tool interface a
> 'fork-is-happening-now' event which tools can ask to see. Then
> only the core needs to be able to detect fork-like syscalls.
Yes. I would prefer such a "cleanup_tool_state_after_fork" hook.
BTW, cachegrind/massif also should have this kind of "problem", or?
Josef
>
> Nick, is that viable from a core-tool-iface-supremo point of view?
>
> J
>
>
|