Just for the curious, here's an update on the current capabilities of the froggy module, expressed as a description of the command line options that exercise them. (This is cut'n'pasted from the latest froggy README.)

       Just to put it all in one place, current usage of froggy-test is as
       follows:

               ./froggy-test [control options] (process specification) ...

       where the optional control options are:

               -q | --quiesce
                       Quiesce the specified process after attaching it.
                       Running processes attached via the -p option (see
                       below) are quiesced according to utrace rules.
                       Processes started via the -E option (e.g., binaries
                       executed by fork/execv) are quieseced when the
                       process is ready to run but has not yet started to
                       do so (in report_exec).

               -e <arg> | --syscall-entry <arg>
                       Enable reporting of entry into syscalls specified by
                       <arg>.  <arg> can be a syscall number (e,g. 3 to
specify entry into the i386 read syscall) or it can be
                       the syscall name (as shown in
                       /usr/include/bits/syscall.h with the SYS_ prefix
removed, e.g., 'read'). It can also be specified as
                       the string "all," in which case reporting of all
                       syscall enties will be enabled.

               -x <arg> | --syscall-exit <arg>
                       Just like --syscall-entry but controls the reporting
                       of syscall exits.

               -s <arg> | --signal <arg>
                       Similar to -e and -x, using the same argument
                       conventions, but for signals.  (NOT YET FULLY
                       IMPLEMENTED.)

               -w | --wait
Causes the client to wait until the specified process
                       is attached.  (Hasn't been tested in a while, might
                       not work, and may be removed.)

       The process specification is one of the following:

               -p <arg> | --pid <arg>
                       Attach to the running process the pid of which is
                       <arg>.

               -E <arg> | --exec <arg>
                       For this option, <arg> is a string specifying a
                       program to be executed and attached, along with any
                       necessary arguments.  E.g.:

                               -E "./reader -i 500000"

starts the test program "reader," passing "-i 500000"
                       to it as arguments, and attaching the resultant
                       process.

Any number of "[control option] (process specification)" sequences can
       be specified.  Once a process has been specified, any previously
       supplied control options are applied to that process and the options
       are cleared.  This permits usages such as:

               ./froggy-test -e read -p 1234 -x write -p 5678

       which would enable reporting of read syscalls from process 1234 and
       write syscalls from process 5678.  -p and -E specifications can be
       used concurrently and will be dealt with in the order specified,
though there is no guarantee I'm aware of that the will be attached by
       utrace in any particular order.  (A -p attach is much simpler than
       the fork()/exec() process needed by -E, which also requires
       synchronisation with the client in various places.)

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


Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to