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
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"
(udb) print return_buffer() + 2 $2 = 0x601052 <buffer+2> "t populated"
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
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
stderr, provided that the debuggee has at no point closed those file
UndoDB currently has an issue (T4695) in which
closed for inferior calls in replay mode if they are not TTYs. This means
stdout will fail in this case. Contact Undo
Support if this is affecting your usage of UndoDB.
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
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