KasperskyOS Community Edition 1.3

Working with processes and threads

In the GDB debugger, objects called inferiors are used to work with processes. The process of each program to be debugged must be attached to a separate inferior. Switching between inferiors is equivalent to switching the debug focus to the context of another process. The debug symbols for the program to be debugged must be loaded after switching to the inferior that is attached to the process of this program.

An inferior is automatically created when the GDB debugger is started. When the GDB debugger connects to the GDB server of the kernel, execution of the solution code stops and this inferior is automatically attached to the process containing the thread in whose context the solution code execution is stopped. All other required inferiors can be created, attached to processes, and detached from processes manually or automatically. In the first case, you need to use the GDB commands for working with inferiors. In the second case, you must configure handling of events in the process life cycle.

GDB commands for working with inferiors

To work with inferiors, you need to use the following GDB commands:

  • info inferiors

    Displays the list of inferiors. The current inferior is marked by the * character. (The context of the process associated with the current inferior is in the debug focus.)

  • add-inferior

    Creates an inferior.

  • inferior <inferior number>

    Switches to another inferior.

  • attach <PID>

    Attaches the current inferior to the process with the specified PID. To print a list of processes, run the GDB command info os processes.

  • detach

    Detaches the current inferior from the process.

Configuring handling of events in the process life cycle

The GDB server of the kernel notifies the GDB debugger about the occurrence of the following events:

  1. Creation of a child process
  2. Start of the initial thread of a child process
  3. Termination of a process

The GDB debugger handles event 1 only if an inferior is attached to the parent process. To handle event 2, the GDB debugger must have previously handled event 1 when the child process was created. In this case, event 2 is handled even if the parent process was already detached from the inferior, for example, due to its termination.

To configure handling of events 1 and 2, use the following GDB commands:

  • set follow-fork-mode {child|parent}

    Instructs the GDB debugger to switch to the context of the child process (child) or to remain in the context of the parent process (parent) when event 1 occurs. The second option is carried out by default.

  • set detach-on-fork {on|off}

    Instructs the GDB debugger to leave the parent or child process attached to the inferior (on) or to leave the parent process attached to the inferior and create a new inferior and attach it to the child process (off) when event 1 occurs. The first option is carried out by default. In this case, the parameter of the GDB command set follow-fork-mode determines which process is attached to the inferior (parent or child).

  • set follow-exec-mode {new|same}

    Instructs the GDB debugger to create a new inferior and attach it to the child process (new) or refrain from doing so (same) when event 2 occurs. The second option is carried out by default.

It is recommended to configure handling of events 1 and 2 as follows:

set follow-fork-mode parent set follow-exec-mode same set detach-on-fork off

This configuration ensures that events 1 and 2 are handled by the GDB debugger as follows:

  • When event 1 occurs, a new inferior is created and attached to the child process.
  • When event 1 occurs, the parent process remains attached to the inferior.
  • When event 2 occurs, a new inferior is not created for the child process.

To avoid using an infinite loop, handling of event 2 by the GDB debugger can be used to stop execution of the program before management is transferred to the main() function.

To stop execution of the program when event 2 occurs, use the following GDB command:

catch exec

This GDB command stops the execution of each child process that was created while event 1 was handled. To stop the execution of individual processes, use the following GDB command:

monitor exec [<name of process 1>][, <name of process 2>]...

A subsequent call of this GDB command cancels the previous call, and calling this command without parameters will stop each child process that was created while event 1 was handled.

Event 3 is handled by the GDB debugger only if inferiors attached to terminated processes are created. When this event is handled, the GDB debugger detaches the inferior from the terminated process. Handling of event 3 does not need to be configured.

GDB commands for working with threads

To print a list of the threads contained in processes attached to inferiors, run the following GDB command:

info threads

The current thread is marked by the * character. (The context of the current thread is in the debug focus.)

To switch to the context of another thread, use the following GDB command:

thread <Id value received by calling the GDB command info threads>

Switching to the context of another thread will result in switching to another inferior if this thread is in a process attached to an inferior different from the current one.