The Teradata C/C++ UDF Debugger extends GDB; therefore all GDB commands that are available for normal debugging are also available for debugging UDFs. Keep in mind that some operations are not safe (or possible) in a massively parallel environment, such as reverse execution and catching certain system calls (such as fork and exec).
When you use the Teradata C/C++ UDF Debugger, all threads attached to the debugger stop when any thread encounters a condition that stops it. The continue command runs all threads (unless they are held); the step and next commands only run the current thread. In contrast, some versions of GDB stop only the threads that encounter a breakpoint (or other condition that will stop them) and all other threads continue to run.
The kill command aborts the current database request when issued in a UDF debugging session, not the attached process as in a normal GDB session. If more than one database session is joined to a debugging session, the kill command ends debugging of any active SQL requests from all joined sessions, but only the request for the current UDF is aborted. Database sessions can then restart queries to continue debugging their UDFs.
The info thread command lists all threads currently known to GDB. When debugging UDFs, it shows each thread selector in the Target Id field and the thread’s current instruction address. This can be useful to identify other UDFs that are running when one stops at a breakpoint.