abt froggy

[Srikar Dronamraju]

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:srikar at sourceware.org:/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,
>                                        &regs);
I see this:
 if (froggy->syscall_fcn)
            (*froggy->syscall_fcn)(resp.resp_syscall.nr,
                                   (pid_t)resp.resp_syscall.pid,
                                   resp.resp_syscall.args,
                                   &regs);
        }

> >
> > 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.