This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Froggy update
- From: Chris Moller <cmoller at redhat dot com>
- To: utrace-devel at redhat dot com, Project Archer <archer at sourceware dot org>
- Date: Wed, 13 Aug 2008 15:58:42 -0400
- Subject: 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
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