UNDODB-LIMITS

NAME

DESCRIPTION

LIMITATIONS

Obscure instructions

Use of AMD 3DNow! and other extended AMD instructions is not supported (though Intel SSE, SSE2, SSE3 and SSE4 instructions are supported). Instructions that modify CS, DS, ES or SS registers are also not supported.

AysncIO

UndoDB does not support asynchronous IO operations: io_cancel io_destroy io_getevents ioperm iopl io_setup io_submit system-calls are all unsupported.

Exec

UndoDB does not support the execve syscall, as used by libc's execl() execlp() , execle() , execv() , execvp() and execve() functions. If the debuggee attempts to issue this system call, execution will not be possible forward beyond this point (though reverse execution is still possible).

Obscure system calls

Certain rarely used system calls are not supported. If the debuggee attempts to issue an unsupported system call, execution will not be possible forward beyond this point (though reverse execution is still possible). The following system calls are either esoteric, or obsolete, and only maintained in the kernel to maintain backwards compatibility with binaries written for early 2.x series kernels: ssetmask modify_ldt pivot_root vm86 unshare

Use of setrlimit()

If the debuggee uses setrlimit to reduce the amount of memory, processes, or other resources that it may consume, then UndoDB may not be able to operate properly due to lack of resources.

Use of x86 inter-segment (aka 'far') jumps/calls

UndoDB does not support the use of far jumps/calls in the debuggee. Any such attempt will result in execution not being able to continue forwards from the point at which the far jump/call instruction is issued.

Non-executable memory

UndoDB ignores the executable status of memory when running code, so code that would usually fail because it is in non-executable memory, will run successfully.

Disk usage

Depending on the debuggee, UndoDB can create large temporary files within /tmp

Statically-linked debuggees

UndoDB cannot start a statically-linked debuggee. However it can attach to an existing statically-linked debuggee process.

Self-modifying code

UndoDB mostly works with self-modifying code, but in some situations the effects of writing into the currently executing "basic block" may be delayed (that is, writing instructions just ahead of the current program counter such that the processor will execute the newly written code by virtue of "running in to" rather than "jumping to" it).

Shared memory accesses straddling valid and invalid pages.

A debuggee access to shared memory where the instruction's operand straddles a page boundary such that the first part of the operand is in accessible shared memory, but the second part is in mapped shared memory which is not backed by a valid shared object (e.g. because the file which is mapped has been truncated) should receive signal SIGBUS. Under UndoDB, a debuggee making such an access will not receive SIGBUS, rather it will read zeroes for the part of the operand that straddles into unbacked memory. Note that normal attempted access to shared memory not backed by a shared object will generate a SIGBUS as normal; it is only a single instruction's access that lies half in valid memory and half in invalid memory that should generate a SIGBUS for which there is a problem.

Breakpoints

All breakpoints used with UndoDB work like hardware breakpoints. In particular, the code where the breakpoint resides is not modified, writes to that code by the program will not remove the breakpoint, and setting a breakpoint not at the first byte of an instruction will have no effect.

System call output buffers

Any system calls that write to memory must be passed a buffer entirely within writable memory. For example, if read() is passed an 8k buffer of which only the first 4k is in user-writable memory, if that read() would normally return 4k or fewer characters then natively it may succeed, but on UndoDB it will fail with EFAULT. If a system call that writes to memory is passed a buffer which is not in writable memory at all, but fails for some other reason before the kernel tries to write to the buffer, then natively it may fail with some error other than EFAULT, but on UndoDB it may fail with EFAULT. If two buffers which overlap are passed to a system call which writes to both of them or reads from one and writes to the other, the behaviour in UndoDB may differ from the native behaviour (although behavior in such cases is liable to vary between kernel versions, too.)

Adjust Flag

According to the Intel manuals, the state of the Adjust Flag (AF) after some instructions is "undefined". On some processor models, different executions of the same code can produce different states of AF. If the behaviour of a program depends on the state of AF when it is supposed to be undefined, the program may not run correctly with UndoDB.

SIGCHLD while attaching

If a SIGCHLD arrives for a process while UndoDB is in the middle of attaching to the process, the SIGCHLD may be silently lost. Once the process has been attached to, SIGCHLD is handled normally.

SEE ALSO

undodb-gdb(1)

http://undo-software.com/

Index

NAME

DESCRIPTION

LIMITATIONS

SEE ALSO