Back to files

DIOTA v0.91

1) Building

To build DIOTA:

        ./configure
        make

You can specify a few compile-time options to change the way DIOTA operates, like this:

make O="-D<option>"

Some useful options are:

• SYSIO_UNLOCKED: this is somewhat a misnomer because of legacy reasons,

  but the main consequence of using it is that all I/O to the logfiles will become unbuffered. This is useful if you have a program that crashes and you want to have all trace-information until right before the crash. WARNING: this slows down tracing tremendously!

• DEBUG: this is mostly useful if you are working on DIOTA itself, it turns

  on ogging of a lot of internal information

2) Usage

To use diota, type:

. alias

This defines an alias for each available backend. In order to use a backend, just type the name of the backend and then execute your dynamically linked program, e.g.

        trace-mem
        ./my-test-application

Diota only attaches itself to applications that can be found (or a file with the same name) in the current directory, e.g.

        trace-mem
        ls

will probably not trace ls (unless you execute this command in /bin), but if you do a

touch ls

first, ls will be traced.

Diota can also instrument statically linked binaries if you put `diota' in front of the the actual command, e.g.

diota ./statically-linked-program

(the diota helper program does not have to reside in the current directory)

Information produced by the backends is written to

/tmp/diota.log-NAMEOFAPPLICATION-USERNAME

Additional information may be found in

        /tmp/diota.log-NAMEOFAPPLICATION-USERNAME.T0
        /tmp/diota.log-NAMEOFAPPLICATION-USERNAME.T1
        ...

These are thread-specific logfiles (.T0 = main program thread). A backend is free to choose in which of these files it puts its output.

For statically linked binaries, a small piece of the diota loader is also traced; the actual trace starts a few lines after

===== restarting from ....
in the log.

You can use different backends at the same time, e.g.

        trace-mem
        trace-code
        ./my-test-application

Type `none' to unset the list of backends to be used, e.g.

        trace-mem
        ./program1
        trace-code
        ./program2
        none
        trace-code
        ./program3
will execute
        ./program1 with the trace-mem backend
        ./program2 with the trace-mem and the trace-code backend
        ./program3 with the trace-code backend

3) Debugging

If you want to use gdb together with diota, define DIOTA_GDB and use diota in the normal way; diota will start gdb for you and attach it to the running program

        [ronsse@SD90MAC ~/work/diota/test] export DIOTA_GDB=1
        [ronsse@SD90MAC ~/work/diota/test] trace-mem
        [ronsse@SD90MAC ~/work/diota/test] ./test
        diota: pid 6022, sleeping 1000 seconds
        diota: environment variable DIOTA_GDB defined, starting gdb
        GNU gdb Red Hat Linux (5.3.90-0.20030710.41rh)
        Copyright 2003 Free Software Foundation, Inc.
        GDB is free software, covered by the GNU General Public License, and
        you are welcome to change it and/or distribute copies of it under
        certain conditions.
        Type "show copying" to see the conditions.
        There is absolutely no warranty for GDB.  Type "show warranty" for details.
        This GDB was configured as "i386-redhat-linux-gnu"...  (no debugging
        symbols found)...Using host libthread_db library
        "/lib/tls/libthread_db.so.1".

        Attaching to program: /user/ronsse/work/diota/test/test, process 6022
        <<cut>>
        (gdb)

Type `c' to continue the execution in gdb. On some setups, you may have to type `ctrl-c' and then c again for the program to really continue, because of a sleep-command and timing differences.

Afterwards, you will almost immediately encounter two SIGSEGV's, and you may encounter more later on. This is normal, and you can ignore them (by typing `c' again).

The cause is the fact that every program contains at least one "call 0x0" instruction, so DIOTA causes this exception when it tries to find out which instructions lie at its target address. As long as the exceptions occur inside the function "diota_asm_getlong()", they will be caught and handled correctly.

Note that you cannot set breakpoints in your code, as an instrumented copy is executed instead of the original program. You still can view the contents of variables, however. You can also translate an instrumentation address to an original program address by typing

p/x diota_translation_lookup_prog_address(<instrumentation_address>)