当前位置: 技术问答>linux和unix
用GDB调试子进程
来源: 互联网 发布时间:2016-10-07
本文导语: GDB调试在默认状态下是调试父进程的,用set follow-fork-mode child可以指定调试子进程 这个命令是不是在有些系统上没有实现啊? 怎么我在Cygwin输入这个命令之后还是在父进程? | Process Creation The fork call ...
GDB调试在默认状态下是调试父进程的,用set follow-fork-mode child可以指定调试子进程
这个命令是不是在有些系统上没有实现啊?
怎么我在Cygwin输入这个命令之后还是在父进程?
这个命令是不是在有些系统上没有实现啊?
怎么我在Cygwin输入这个命令之后还是在父进程?
|
Process Creation
The fork call in Cygwin is particularly interesting because it does not map well on top of the Win32 API. This makes it very difficult to implement correctly. Currently, the Cygwin fork is a non-copy-on-write implementation similar to what was present in early flavors of UNIX.
The first thing that happens when a parent process forks a child process is that the parent initializes a space in the Cygwin process table for the child. It then creates a suspended child process using the Win32 CreateProcess call. Next, the parent process calls setjmp to save its own context and sets a pointer to this in a Cygwin shared memory area (shared among all Cygwin tasks). It then fills in the child's .data and .bss sections by copying from its own address space into the suspended child's address space. After the child's address space is initialized, the child is run while the parent waits on a mutex. The child discovers it has been forked and longjumps using the saved jump buffer. The child then sets the mutex the parent is waiting on and blocks on another mutex. This is the signal for the parent to copy its stack and heap into the child, after which it releases the mutex the child is waiting on and returns from the fork call. Finally, the child wakes from blocking on the last mutex, recreates any memory-mapped areas passed to it via the shared area, and returns from fork itself.
While we have some ideas as to how to speed up our fork implementation by reducing the number of context switches between the parent and child process, fork will almost certainly always be inefficient under Win32. Fortunately, in most circumstances the spawn family of calls provided by Cygwin can be substituted for a fork/exec pair with only a little effort. These calls map cleanly on top of the Win32 API. As a result, they are much more efficient. Changing the compiler's driver program to call spawn instead of fork was a trivial change and increased compilation speeds by twenty to thirty percent in our tests.
However, spawn and exec present their own set of difficulties. Because there is no way to do an actual exec under Win32, Cygwin has to invent its own Process IDs (PIDs). As a result, when a process performs multiple exec calls, there will be multiple Windows PIDs associated with a single Cygwin PID. In some cases, stubs of each of these Win32 processes may linger, waiting for their exec'd Cygwin process to exit.
===========
http://www.cygwin.com/ml/gdb/2001-02/msg00364.html
有可能不支持。
The fork call in Cygwin is particularly interesting because it does not map well on top of the Win32 API. This makes it very difficult to implement correctly. Currently, the Cygwin fork is a non-copy-on-write implementation similar to what was present in early flavors of UNIX.
The first thing that happens when a parent process forks a child process is that the parent initializes a space in the Cygwin process table for the child. It then creates a suspended child process using the Win32 CreateProcess call. Next, the parent process calls setjmp to save its own context and sets a pointer to this in a Cygwin shared memory area (shared among all Cygwin tasks). It then fills in the child's .data and .bss sections by copying from its own address space into the suspended child's address space. After the child's address space is initialized, the child is run while the parent waits on a mutex. The child discovers it has been forked and longjumps using the saved jump buffer. The child then sets the mutex the parent is waiting on and blocks on another mutex. This is the signal for the parent to copy its stack and heap into the child, after which it releases the mutex the child is waiting on and returns from the fork call. Finally, the child wakes from blocking on the last mutex, recreates any memory-mapped areas passed to it via the shared area, and returns from fork itself.
While we have some ideas as to how to speed up our fork implementation by reducing the number of context switches between the parent and child process, fork will almost certainly always be inefficient under Win32. Fortunately, in most circumstances the spawn family of calls provided by Cygwin can be substituted for a fork/exec pair with only a little effort. These calls map cleanly on top of the Win32 API. As a result, they are much more efficient. Changing the compiler's driver program to call spawn instead of fork was a trivial change and increased compilation speeds by twenty to thirty percent in our tests.
However, spawn and exec present their own set of difficulties. Because there is no way to do an actual exec under Win32, Cygwin has to invent its own Process IDs (PIDs). As a result, when a process performs multiple exec calls, there will be multiple Windows PIDs associated with a single Cygwin PID. In some cases, stubs of each of these Win32 processes may linger, waiting for their exec'd Cygwin process to exit.
===========
http://www.cygwin.com/ml/gdb/2001-02/msg00364.html
有可能不支持。
|
确实,我在很多平台上用的gdb都不是完全一样,基本的命令式一样的,有些和平台有关的命令就难说了
|
这样做:
1 在你的子进程代码中写一段无用程序,比如fake_func(),确保父进程不会执行这段程序,然后断点到这里。run...
1 在你的子进程代码中写一段无用程序,比如fake_func(),确保父进程不会执行这段程序,然后断点到这里。run...
|
可以用attach试试。。。
|
lz设置断点了么?在子进程里
http://www.ibm.com/developerworks/cn/linux/l-cn-gdbmp/index.html
http://www.ibm.com/developerworks/cn/linux/l-cn-gdbmp/index.html
|
你可以打开另一个gdb使用 attach