PDA

View Full Version : Are there any limitations of the ReplayEngine?



rwcom
08-15-2011, 02:05 PM
Attaching to a process.

ReplayEngine only supports attaching to a multi-threaded program that is running a Linux kernel version of 2.6 or higher. Attaching to a running multi-threaded process running on a system with a 2.4 kernel will cause RE to only attach to one thread.
ReplayEngine requires that gcc and objcopy be present when attaching to an existing program; they are usually already installed on Linux development machines.
Attaching to a program that is already using shared memory will fail.


Breakpoints


All breakpoints utilize hardware breakpoints. This means that ReplayEngine does not modify the code where the breakpoint resides, writes to that code do not remove the breakpoint, and setting a breakpoint that is not at the first byte of an instruction has no effect.

Disk usage


Depending on the program, ReplayEngine can create large temporary files within /tmp.

Exec


ReplayEngine does not support the __NR_execve system call used by the following libc functions: execl(), execlp(), execle(), execv(), execvp(), and execve().

Some instructions are not supported


Using the Intel SSE3 and SSE4, AMD 3DNow!, and other extended AMD instructions is not supported. Instructions that modify the CS, DS, ES or SS instructions are also not supported. However, the SSE and SSE2 instructions are supported.
Instructions that reference the %ss register are not supported by ReplayEngine. However these instructions occur in the VDSO page on some x86-64 systems. Debugging 32-bit programs is not possible on these systems.

Non-executable memory



ReplayEngine ignores the executable status of memory when running code. This means that code that would usually fail because it is in non-executable memory runs successfully

Obscure system calls


Certain rarely used system calls are not supported. If your program attempts to use one of these calls, forward execution cannot continue. However reverse execution is still possible. Here are the non-supported calls:
__NR_arch_prctl
_NR_get_thread_area
__NR_io_cancel
__NR_io_destroy
__NR_io_getevents
__NR_io_setup
__NR_io_submit
__NR_ioperm
__NR_iopl
__NR_modify_ldt
__NR_pivot_root
__NR_set_thread_area
__NR_shmat
__NR_shmctl
__NR_shmdt
__NR_shmget
__NR_sigsuspend
__NR_sigpending
__NR_sigprocmask
__NR_ssetmask
__NR_unshare
__NR_vm86

While calls such as __NR_sigsuspend may look standard, they have been replaced. For example, __NR_sigsuspend was superseded some years ago by __NR_rt_sigsuspend.

OS/CPU


ReplayEngine only works on 32-bit Linux on x86 and 64-bit Linux on x86-64 CPUs.

Segment Registers


ReplayEngine does not support applications that use segment registers. The registers are $cs, $ss, $ds, $es, $fs, and $gs. If your application uses one of these registers, the process is halted and the thread status title bar contains “Replay error encountered” and your PC should be pointing to the instruction that uses one of these registers.

Self-modifying code


ReplayEngine usually works with self-modifying code. In some cases, writing into the currently executing “basic block” can be delayed; that is, writing instructions just ahead of the current program counter such that the processor will execute the newly written code because it is running into” rather than “jumping to” the code.

setrlimit()


If the program uses setrlimit() to reduce the amount of memory, processes, or other resources, ReplayEngine may not operate properly due to the lack of resources.

Shared memory


ReplayEngine does not support programs that use shared memory. However, there may be ways you can workaround this issue. Please see the details in the shared memory limitations FAQ (http://forum.totalviewtech.com/gforum.cgi?post=484).

SIGINT masking


If your program masks a SIGNIT, ReplayEngine suppresses it.

SIGKILL


ReplayEngine may not work correctly if your program was terminated by SIGKILL.

Statically linked programs


ReplayEngine cannot start a statically-linked program. However, it can attach to an already running statically-linked program.


Josh Carlson