|
0
|
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.
|
