This is the mail archive of the mailing list for the Archer project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Froggy update

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

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

-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

               -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

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]