This document describes the files included with the remote source level debugger, as well as changes for this version.
The following files are distributed with this product:
CLIENT32 RDEBUGLG.BMP HSEARCHR.DLL RDEBUG.HLP RDEBUG.EXE SERVER RDEBUG.NLM SAMPLES TEST3.C TEST.C TEST.SYM TEST.NLM MAKEFILE.MAK
New Features in This Version
1. The debugger now supports command line parameters for NLMs loaded from the client workstation with the "load" command.
2. A new menu option has been added to the Configure menu, which enables the user to tell the debugger to stop on all NLM loads, or only on the NLM which is specifically loaded with the "load" command. If you ask the debugger to stop on all NLM loads, control will be returned to the RDEBUG client each time an NLM loads. If you do not check this option, control will be returned only when an NLM that has been specifically loaded, (as in "load myNLM"), loads.
3. A new invocation option "-unicode" has been added to allow processing of unicode strings.
4. The "threads" command has changed, now displaying all threads in the system.
5. The "queues" command has been replaced with the "waitingthreads" command.
6. A new "runqueue" command has been added
| xrdb1.exe | 2.8 M | 2005-04-06 |
The debugger is a remote debugger. To run the debugger, an NLM called, RDEBUG.NLM is required on the NetWare server and three client pieces, RDEBUG.EXE, RDEBUG.HLP, and HSEARCHR.DLL are required on a Windows/Windows95/WindowsNT machine. Installing the Debugger 1. Copy the files in the CLIENT32 directory to a directory of your choice on the Windows client machine. Copy RDEBUG.HLP and RDEBUGLG.BMP to the same directory that you copied RDEBUG.EXE to. Copy HSEARCHR.DLL to your WINDOWSSYSTEM directory. 2. On Green River servers, copy RDEBUG.NLM to the SYS:SYSTEM directory of the server. (On releases after Green River, RDEBUG.NLM will not be needed on the server.) 3. Configure RDEBUG.EXE on the workstation as described in either the serial or Ethernet section below. 4. Configure RDEBUG.NLM on the server as explained in either the serial or Ethernet section below. 5. Run the debugger by following these steps: a. Load RDEBUG.NLM on the server (LOAD RDEBUG) b. Break into the NetWare internal debugger (SHIFT, SHIFT, ALT, ESC) c. Invoke RDEBUG from within the internal debugger, adding such parameters as are not contained in the RDEBUG.CFG file. d. On the workstation invoke RDEBUG.EXE with appropriate parameters e. From within Rdebug on the client, set the source path to include both the directory containing source files, and the directory containing the symbol file. f. Load the NLM that you wish to debug from within the debugger by typing "load " in the debugger command window. Using the Ethernet Interface The Ethernet interface uses the UDP/IP transport protocol. Routing is supported by using ARP. To use the ethernet interface, you must have 2 IP addresses. One for the server and one for the workstation. For the workstation -- You must install a TCP/IP protocol stack, and WLIBSOCK.DLL and WINSOCK.DLL. These can be obtained from Lan Workplace for Windows for Windows 3.1, or by installing the Microsoft TCP/IP protocol from the Network Control Panel in Windows 95, or Windows NT. You should then edit the properties of the program and add as a parameter to RDEBUG.EXE, the following: -ip where is the IP address of the server. For example: C:RDEBUG32RDEBUG.EXE -ip 111.222.333.444 For the server -- You need an NE2000 board in your machine. At the moment, this is the only Ethernet card that is supported. This card should be in addition to the LAN card that is used by your server for regular network communication, however it is possible to debug using a single NE2000 in the server. In such a case however, the debugger will take over the NE2000 card and the NetWare Server will not have access to the card. As was mentioned above, RDEBUG.NLM is invoked from the NetWare Internal Debugger. Thus, after loading RDEBUG.NLM, you should break into the Internal Debugger by pressing SHIFT, SHIFT, ALT, ESC. Then invoke Rdebug with the appropriate command line. An example would be: #Rdebug NE2000 IP 111.222.333.444 port=320 Parameter information can be obtained by typing "rdebug help" from within the NetWare Internal debugger. If you don't want to type in the IP address every time you invoke the debugger you can put it in a file, on the DOS partition, and in the boot directory. The file is named RDEBUG.CFG and should contain only one line in the file, with the following format: NE2000 IP port= for example: NE2000 IP 111.222.333.444 port=320 Note that port is the port address of the NE2000 card you are using for the debugger. No LAN driver should be loaded by the server for the NE2000 card that will be used by the debugger. RDEBUG.NLM contains a special NE2000 driver that will control the additional LAN card. Using a serial interface If you want to use the serial interface you must have a serial cable between the server and the workstation. For the workstation -- The debugger defaults to COM1. However you may override this by specifying the COM port on the command line of RDEBUG.EXE. The format is as follows: -port for example: C:RDEBUG32RDEBUG.EXE -port COM2 The debugger also defaults the baud rate for Windows 3.1 to 38400 baud, and for WindowsNT or Windows95 to 57600 baud. You may override the baud rate by specifying the baud rate on the command line as follows: -baud The debugger supports the following baud rates: 300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600 If you specify a baud rate, but it is not one of the above, the debugger will use the default for the operating system on which it is running. The port and baud parameters need not be in any specific order For the server -- If you are not using COM1 you may either type the port as part of the command to invoke RDEBUG, as in #RDEBUG COM2 or put it in the RDEBUG.CFG file. This file is on the DOS partition, and in the boot directory. It should only have one line in the file, with the following format: COM2 You do not need to specify a baud rate on the server. When the initial connection is made with the workstation, the correct baud rate will be determined. However, should you break into the NetWare Internal debugger while running RDEBUG, and then wish to reconnect to the workstation, it will be necessary to specify the baud rate at which the two were connected previously. An example of this is as follows: #RDEBUG BAUD 38400 When the workstation initially connects with the server, the negotiated baud rate will appear on the screen. Things you need to know: 1. The source code can be anywhere, but must be pointed to by the spath and/or the global path variables. These are setable from the menu or from the command window. 2. The symbol file (xxx.SYM) must be in a directory pointed to by either the spath or global path variables, or in the directory you run RDEBUG.EXE from. 3. When you load your NLM from the debugger, it will load the NLM, then proceed to the Start Procedure of the NLM. For NLMs written to use CLIB, this will be PRELUDE.OBJ. There are no symbols for this, however you may see line numbers and assembly code following them. You can proceed to your own code by either selecting one of your modules, setting a breakpoint and clicking "go", or by typing "go til main" (or any other function name) in the command window, which will bring you that function. 4. If you step into a function for which you have no source code, it will take a long time and not step in, but rather step over the line. You can step in if you are in assembly mode (settable by pressing the ASM button), only. 5. The NLM only runs on GreenRiver versions of NetWare, you cannot debug on 4.10, 3.12, 3.11, or anything else. This is because NetWare servers prior to GreenRiver did not contain support for the debugger. 6. The concept of viewpoint is mentioned throughout the documentation, but the definition of a viewpoint for NetWare is currently the set of all NLMs on the server that have symbols for them. This may change in the future to include the concept of threads, processes, or processors. 7. When the debugger starts up, it will load symbols for any NLM that is currently loaded on the server, provided it finds the symbol file in the startup directory, or in the directory pointed to by spath or global path. 8. You can debug multiple NLMs at the same time because of the way viewpoints are defined as described above. A current problem exists however, that causes duplicate module (compilation unit) names to be thrown away. So, if you had 2 NLMs that each had a DOG.C file in them, and you loaded symbols for both NLMs, in the modules list (the debugger modules list, not the NetWare server modules list), you would only see one instance of DOG as a module. This would be the first one loaded. Should you step into any function in the DOG module for the second NLM you wouldn't be able to see symbols or source code. 9. Using the Watcom compiler, you must compile your code with the /hc switch (see makefile) 10. Using the Watcom linker, you must link with the "debug codeview" link option (see makefile) 11. You must run CVPACK.EXE after linking (see makefile)
© 2008 Novell, Inc. All Rights Reserved.
