Note: If a process already exists, you can have the debugger attach to it:
attach_command
attach_command
: attach pid
Note: The attach command requires the name of executable to be specified before attaching to the process. Use the file command or shell command line to specify the filename.
The process is specified by its pid:
pid
For example:
(idb) attach 12345 a.out
(idb) file a.out
Reading symbols from a.out...done.
(idb) attach 12345
Note that you must specify the file name. The file name should be the executable file that is executing or a duplicate copy of it. You may omit the executable file name only if the debugger already has the file loaded. It means that if a file name is not specified, the current executable is used. If the executable contains symbolic debug information it will be read by the debugger during the attach.
Attaching to a process both creates the debugger's knowledge of it and makes it the current process that the debugger is controlling. The process continues execution until it raises a signal that the debugger intercepts. Usually you do this by pressing Ctrl+C or by using the shell command kill in another window. Any other mechanism for raising a signal within the process will also do. You can set the debugger variable $stoponattach to 1 to direct the debugger to immediately stop any process that it attaches to.
(idb) ^C
Interrupt (for process)
Stopping process localhost:16077 (loop.out).
Thread received signal INT
stopped at [int main(void):3 0x120001100]
3 while (1) ;
The opposite of attaching to a process is detaching from a process. When you detach the debugger from a process, all breakpoints are removed and the process continues to run, but the debugger can no longer identify or control it:
detach_command
: detach pid ,...
For example:
(idb) detach 12345, 789
: detach
The detach command detaches the debugger from a current process and, therefore, does not require pid.