|
From: Julian S. <js...@ac...> - 2006-09-20 23:14:32
|
> __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, but I think a complete solution to the fork
will have to be in 3.3.X.
> > 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.
Nick, is that viable from a core-tool-iface-supremo point of view?
J
|