ICAT: The New Remote Source-code Debugger for OS/2Written by Chris Matthews and Dave Evans |
IntroductionThere's great news for all of you OS/2 developers! We are proud to introduce a new remote debugger for you to debug source-level code for your OS/2 Warp device drivers, installable file system (IFS) binaries, and applications -- all to increase your productivity during debug time. This might sound familar if you subscribed to DevCon. We previously ran an article about ICAT when we shipped the original debugger on DevCon 11 and 12 around the release of Warp 4.0 and Warp 4.0 Server SMP, but a lot has changed since then. The new debugging environment is the Remote Interactive Code Analysis Tool (Remote ICAT) for OS/2, which you can install from the Toolkit category of the Developer Connection catalog or from the ICAT home page off the DDK (Device Driver Developer Kit) Area. Remote ICAT is a two-system setup that piggybacks on the kernel debugger (KDB) and works on these versions of the target machine: OS/2 Warp 4.0 Version 4, Warp Server 4.0 SMP Version, and OS/2 Warp Version 3.0 at FixPak 24 or later. Remote ICAT lets you debug a target OS/2 system from a remote host with the familiar IPMD/ICSDEBUG debugger interface. This makes it easier to debug VIO and PM applications, IFS binaries, and device drivers, especially drivers using the new adapter device driver (ADD) and graphics ADD (GRADD) modules written in C. Here are some of the features of the new debugger:
Operation of the DebuggerIn the initial setup of the remote debugger, the target machine contains any of your IFS, physical device driver (PDD), virtual device driver (VDD), or application code to be debugged. These must be compiled and linked using debug flags (the specific flags depend on your compiler and linker). If file size is a problem, you can strip debug information from the binaries before putting them on the target machine, but they must be generated with the debug information initially.
The real debugging work is done on the host machine connected to the remote target machine through the COMx port (the same setup that KDB already uses). The host machine maintains the unstripped version of the debug binary files and the source used for building the binaries. The Remote ICAT debugger depends on the host machine's environment variables to access the directories that contain the debug binaries and source files. This allows Remote ICAT to debug device drivers, IFS binaries, or applications at the source level. Once the initial setup of the target and host system is completed, the debugger environment is created to establish communication information, source and binary paths, module list selection, and other Remote ICAT options. Then Remote ICAT can be started. It takes a few seconds for Remote ICAT to initialize communication with the target system, but once the communication is established, the following initialization dialog is displayed. Select Attach to complete the connection.
Note: If you experience a communication problem, check to make sure that there is not a terminal emulator program running that competes for the COMx port. Also check to see if you can bring up KDB under a terminal emulator program (without Remote ICAT running) and communicate successfully. Don't forget to shut this terminal emulator down before retrying the Remote ICAT connection. When the connection is complete, the debugger opens a Debugger Session Control (DSC) window. This window displays a list of Slots (process and thread IDs) along with the modules that are being debugged. Note: If you do not see your module in the list, it may mean that the module was not compiled with the debug flags, the module was not found in Remote ICAT's binary search path, or that the target module was excluded due to an environment variable. Notice that all the processes running in the system are displayed in the process list. This is because the source-code debugger piggybacks on KDB so that it comes in at the supervisor level just as KDB does. This gives the source-code debugger the flexibility to do things like debug an application and device driver in the same debug session at the source-code level with the same tool. You can watch your application call into your device driver and debug the device driver as the call enters the strategy routine. It also allows you to switch context between applications on the fly. These are things you can only do with KDB. Once the kernel attachment is complete, you can select a module from the module list in the DSC window and then select the source code for the function you want to debug. Then you can set a breakpoint and let Remote ICAT run. When the breakpoint is hit, you can unwind the stack, look at storage, monitor properties of a variable, and so forth. At any time during the debug session, you can use the Passthru window to look at things like the global descriptor table (GDT), local descriptor table (LDT), and so forth. (Click for large version) What about Network debugging ?Well this is something new we have added to ICAT. The network solution we have today is a three-tiered solution. It still needs a COM port connection to the target machine but requires a mediator (bridge) system between the host and the target system. The mediator (bridge) system can be OS/2 or NT (see the illustration below). For more information on how to set up the connection see the ICAT home page off the DDK (Device Driver Developer Kit) Area.
We have also provided a remote console monitor. The remote console monitor allows you to monitor a series of systems throughout your network and notify you of problems as they occur. It communicates directly with the mediator (bridge) daemon for status information. We are revamping the monitor into a more upscale GUI monitor, but we have a lightweight version available now. Where are we going ?You probably guessed it. We would like to get to an OS/2 point-to-point network debugging solution for ICAT and kernel debugger. This would remove the requirement for the mediator system and allow a direct debug connection from host to target over the network, but we are not sure when this will be available. If and when it is available, we will announce it on the ICAT home page or on EDM/2. See the illustration below for more information on future plans of OS/2 point-to-point debugging.
Helpful Remote ICAT Debugging TipsThe following are some Remote ICAT debugging tips that can be helpful for both novices and more advanced users.
ConclusionYou should now be on your way to successful remote source-code debugging of system-level binaries. We will continue to provide quality enhancements and features to the debugger, and your feedback is always welcome! Please send your comments to Chris Matthews or Dave Evans. |