Srikar Dronamraju wrote: > 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); > } >
Yeah, that's the bleeding edge as of yesterday afternoon after I sent
that note--froggy's changing fairly rapidly.
>
>>> 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,
Look two lines above that--there's a #ifdef DO_AUTOATTACH and
DO_AUTOATTACH isn't being set in the build. (This is my way of doing
hacks I may want to reverse if they don't work right. Since things are
playing the way I expect them to, for the next snapshot I'll probably
delete all the code currently wrapped up in DO_AUTOATTACH #ifdefs--it
exists in five places in three separate files.)
>
>
>> 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.
>
The absolute latest snapshot was at 1704 East Coast U.S. time
yesterday. Yes, there's a small overlap between the code in
do_process_detach and do_shutdown, but that's a micro-optimisation I can
do something about when the major stuff is working. (Shutdown and
detach are fairly sensitive w.r.t. race conditions and what happens
depending on whether the client kills a child, the child is killed
externally, or the client is killed or dies--I don't tinker casually in
that area.)
>
>>> 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.)
>
I'll be doing a lot of documentation work over the next few days--no
reason I can't include a tentative roadmap.
>
>>> 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.
>
>
--
Chris Moller
I know that you believe you understand what you think I said, but
I'm not sure you realize that what you heard is not what I meant.
-- Robert McCloskey
signature.asc
Description: OpenPGP digital signature
