1 This is a "Simple Windows Debug Server" written for the purpose of |
|
2 enabling the Serviceability Agent on Win32. It has backends both for |
|
3 Windows NT 4.0 (using internal Windows APIs for a few routines) as |
|
4 well as for 95/98/ME/2000 via the Tool Help APIs. |
|
5 |
|
6 The reason this debug server is necessary is that the Win32 debug APIs |
|
7 by design tear down the target process when the debugger exits (see |
|
8 knowledge base article Q164205 on msdn.microsoft.com). On Solaris, one |
|
9 can attach to and detach from a process with no effect; this is key to |
|
10 allowing dbx and gcore to work. |
|
11 |
|
12 The Simple Windows Debug Server effectively implements attach/detach |
|
13 functionality for arbitrary debug clients. This allows the SA to |
|
14 attach non-destructively to a process, and will enable gcore for Win32 |
|
15 to be written shortly. While the debugger (the "client" in all of the |
|
16 source code) is attached, the target process is suspended. (Note that |
|
17 the debug server could be extended to support resumption of the target |
|
18 process and transmission of debug events over to the debugger, but |
|
19 this has been left for the future.) |
|
20 |
|
21 The makefile (type "nmake") builds two executables: SwDbgSrv.exe, |
|
22 which is the server process, and SwDbgSub.exe, which is forked by the |
|
23 server and should not be directly invoked by the user. |
|
24 |
|
25 The intent is that these two executables can be installed into |
|
26 C:\WINNT\SYSTEM32 and SwDbgSrv installed to run as a service (on NT), |
|
27 for example using ServiceInstaller (http://www.kcmultimedia.com/smaster/). |
|
28 However, SwDbgSrv can also be run from the command line. It generates |
|
29 no text output unless the source code is changed to enable debugging |
|
30 printouts. As long as any processes which have been attached to by the |
|
31 SA are alive, the SwDbgSrv and any forked SwDbgSub processes must be |
|
32 left running. Terminating them will cause termination of the target |
|
33 processes. |
|
34 |
|
35 The debug server opens port 27000 and accepts incoming connections |
|
36 from localhost only. The security model assumes that if one can run a |
|
37 process on the given machine then one basically has access to most or |
|
38 all of the machine's facilities; this seems to be in line with the |
|
39 standard Windows security model. The protocol used is text-based, so |
|
40 one can debug the debug server using telnet. See README-commands.txt |
|
41 for documentation on the supported commands. |
|
42 |
|
43 Testing indicates that the performance impact of attaching to a |
|
44 process (and therefore permanently attaching a debugger) is minimal. |
|
45 Some serious performance problems had been seen which ultimately |
|
46 appeared to be a lack of physical memory on the machine running the |
|
47 system. |
|
48 |
|
49 Bugs: |
|
50 |
|
51 This debug server is fundamentally incompatible with the Visual C++ |
|
52 debugger. Once the debug server is used to attach to a process, the |
|
53 Visual C++ IDE will not be able to attach to the same process (even if |
|
54 the debug server is "detached" from that process). Note that this |
|
55 system is designed to work with the same primitives that C and C++ |
|
56 debuggers use (like "symbol lookup" and "read from process memory") |
|
57 and exposes these primitives to Java, so in the long term we could |
|
58 solve this problem by implementing platform-specific debug symbol |
|
59 parsing and a platform-independent C++ debugger in Java. |
|
60 |
|
61 Note: |
|
62 |
|
63 The files IOBuf.cpp and IOBuf.hpp are also used in |
|
64 building src/os/solaris/agent. |
|