Inferior Calls

Inferior calls are a way for a user to run code inside a debuggee, usually in order to observe some internal state. These calls are part of expressions that are evaluated for commands such as call and print.

For example, if the debuggee had a function named return_buffer() this could be called with the following:

(udb) print return_buffer()
$1 = 0x601050 <buffer> "not populated"

print supports complete GDB expressions, so you can perform operations such as:

(udb) print return_buffer() + 2
$2 = 0x601052 <buffer+2> "t populated"

Side Effects

In order to support inferior calls in replay or for loaded recordings, UndoDB runs all inferior calls in a temporary process known as a “volatile copy” which is fork()-ed from the original debuggee process. This temporary process is said to run in “volatile mode”. This means that all side effects, such as writes to memory, are effectively reverted after the inferior call completes and are not written into the recorded history of the debuggee (and therefore do not appear in saved recordings).

The only external state changes that are defined are writes to stdout and stderr, provided that the debuggee has at no point closed those file descriptors.

Note

UndoDB currently has an issue (T4695) in which stderr and stdout are closed for inferior calls in replay mode if they are not TTYs. This means writes to stderr and stdout will fail in this case. Contact Undo Support if this is affecting your usage of UndoDB.

Non-deterministic calls

If a non-deterministic system call is made from the UndoDB prompt, the call will be executed in the volatile copy and the result will be determined by a combination of the process state at that point in history and the current system state. For example, if gettimeofday is called from the UndoDB prompt, the printed output will always contain the current time.

However, if the debuggee’s program code uses the result of the gettimeofday system call to determine its subsequent execution, then that result is considered to be part of the debuggee’s process state, and if that result is printed at the UndoDB prompt, the printed output will contain the result of the gettimeofday system call at the time the debuggee process was originally recorded.