Hi Chris,
Thanks for your quick reply.
I have been regularly updating from cvs. So I thought I was always on
the latest copy. To confirm I checked out a new copy using
cvs -z9 -d :ext:[EMAIL PROTECTED]:/cvs/systemtap co froggy
and compared it the copy I update regularly and they seem to be identical.
>
> The printf()s in froggy.c:resp_listener() are all temporary diagnostics
> and will ultimately be removed. I don't know which version of froggy
> you have, but if you'll look at the latest under the RESP_SYSCALL_ENTRY
> case you'll see:
>
> if (froggy->syscall_fcn)
> (*froggy->syscall_fcn)(resp.resp_syscall.nr,
> (pid_t)resp.resp_syscall.pid,
> ®s);
I see this:
if (froggy->syscall_fcn)
(*froggy->syscall_fcn)(resp.resp_syscall.nr,
(pid_t)resp.resp_syscall.pid,
resp.resp_syscall.args,
®s);
}
> >
> > In froogy/module/control.c
> > do_process_attach_task() and do_process_attach share lot of code and we
> > could probably use common function for the shared code.
> >
>
> do_process_attach_task() has been removed. Originally, I had it set up
> such that client-thread report_clone wasa used to automatically attach
I am not sure what you mean by removed.
grep -n do_process_attach_task froggy/froggy/module/control.c shows
65:do_process_attach_task (struct utrace_attached_engine * engine,
> child processes that were ultimately to be execve()ed as code to be
> debugged, but I've replaced that with something more explicitly like
> ptrace(PTRACE_TRACEME,...) and the older code has been #ifdef-ed out.
> (I'll remove it entirely when I'm sure I don't need it anymore...)
>
> > Similarly do_shutdown() shares code with do_process_detach and we could
> > probably make do_shutdown() call do_process_detach.
> >
>
> It sounds like you don't have the latest snapshot--I did a /lot/ of
> cleanup in the shutdown/detach code last week and fcns you mention split
> the work up differently now.
>
I am not sure if we are looking at the version with different viewpoints
or we are looking at different version of sources.
> > Do we plan to use report_jctl in the near future. utrace_ops has
> > report_jctl set to NULL however we have defined report_jctl() function
> > which never gets used. Similarly for unsafe_exec and tracer_task.
> >
>
> All the report_* callbacks will ultimately be returned to the client for
> handling as described above--keep in mind froggy is still in its early
> stages and there's a lot more that's yet to be done.
Do you have a document that talks of the features and stuff that you
intend to provide other than the README which talks of froggy being a
sandbox for utrace.
(I haven't read the documents that were updated today. Sorry if its
covered in those docs.)
>
> > Can you explain why you would want to attach with
> > UTRACE_ATTACH_EXCLUSIVE always? So even if I want to trace the same
> > program twice from froggy then I shouldn't be able to do it?
> >
>
> To be honest, I had no good reason for using UTRACE_ATTACH_EXCLUSIVE and
> can certainly experiment with removing it.
Ok.
