Document revision date: 30 March 2001 | |
Previous | Contents | Index |
The SCD host and the target kernel use a private Ethernet protocol to communicate. For the two systems to see each other, they have to be on the same Ethernet segment.
The network portion of the target system finds the first Ethernet
device and communicates through it. The network portion of the host
system also finds the first Ethernet device and communicates through
it. However, if for some reason, SCD picks the wrong device, you can
override this by defining the logical DBGHK$ADAPTOR to the template
device name for the appropriate adaptor.
8.9 Troubleshooting Checklist
If you have trouble starting a connection, perform the following tasks to correct the problem:
There are three possible network errors:
The netfail error message has a status code that can be one of the following values:
Value | Status |
---|---|
2, 4, 6 | Internal network error, submit a problem report to Compaq. |
8,10,14,16,18,20,26,28,34,38 | Network protocol error, submit a problem report to Compaq. |
22,24 | Too many errors on the network device most likely due to congestion. Reduce the network traffic or switch to another network backbone. |
30 | Target system scratch memory not available. Check DBGTK_SCRATCH. If increasing this value does not help, submit a problem report to Compaq. |
32 | Ran out of target system scratch memory. Increase value of DBGTK_SCRATCH. |
All others | There should not be any other network error codes printed. If one occurs that does not match the previous ones, submit a problem report to Compaq. |
Accessing OpenVMS executive images' symbols is not always
straightforward with SCD. Only a subset of the symbols may be
accessible at one time and in some cases, the symbol value the debugger
currently has may be stale. To understand these problems and their
solutions, you must understand how the debugger maintains its symbol
tables and what symbols exist in the OpenVMS executive images. The
following sections briefly summarize these topics.
8.11.1 Overview of How the OpenVMS Debugger Maintains Symbols
The debugger can access symbols from any image in the OpenVMS loaded system image list by reading in either the .DSF or .EXE file for that particular image. The .EXE file contains information only about symbols that are part of the symbol vector for that image. The current image symbols for any set module are defined. (You can tell if you have the .DSF or .EXE file by doing a SHOW MODULE. If there are no modules, you have the .EXE file.) This includes any symbols in the SYS$BASE_IMAGE.EXE symbol vector for which the code or data resides in the current image. However, you cannot access a symbol that is part of the SYS$BASE_IMAGE.EXE symbol vector that resides in another image.
In general, at any one point in time, the debugger can access only the symbols from one image. It does this to reduce the time it takes to search for a symbol in a table. To load the symbols for a particular image, use the SET IMAGE command. When you set an image, the debugger loads all the symbols from the new image and makes that image the current image. The symbols from the previous image are in memory, but the debugger will not look through them to translate symbols. To remove symbols from memory for an image, use the CANCEL IMAGE command (which does not work on the main image, SYS$BASE_IMAGE).
There is a set of modules for each image the debugger accesses. The symbol tables in the image that are part of these modules are not loaded with the SET IMAGE command. Instead they can be loaded with the SET MODULE <module-name> or SET MODULE/ALL commands. As they are loaded, a new symbol table is created in memory under the symbol table for the image. Figure 8-1 shows what this looks like.
Figure 8-1 Maintaining Symbols
When the debugger needs to look up a symbol name, it first looks at the current image to find the information. If it does not find it there, it then looks into the appropriate module. It determines which module is appropriate by looking at the module range symbols which are part of the image symbol table.
To see the symbols that are currently loaded, use the debugger's SHOW
SYMBOL command. This command has a few options to obtain more than just
the symbol name and value. (See the OpenVMS Debugger Manual for more details.)
8.11.2 Overview of OpenVMS Executive Image Symbols
Depending on whether the debugger has access to the .DSF or .EXE file, different kinds of symbols could be loaded. Most users will have the .EXE file for the OpenVMS executive images and a .DSF file for their private images---that is, the images they are debugging.
The OpenVMS executive consists of two base images, SYS$BASE_IMAGE.EXE and SYS$PUBLIC_VECTORS.EXE, and a number of separately loadable executive images.
The two base images contain symbol vectors. For SYS$BASE_IMAGE.EXE, the symbol vector is used to define symbols accessible by all the separately loadable images. This allows these images to communicate with each other through cross-image routine calls and memory references. For SYS$PUBLIC_VECTORS.EXE, the symbol vector is used to define the OpenVMS system services. Because these symbol vectors are in the .EXE and the .DSF files, the debugger can load these symbols no matter which one you have.
All images in the OpenVMS executive also contain global and local
symbols. However, none of these symbols ever gets into the .EXE file
for the image. These symbols are put in the specific module's section
of the .DSF file if that module was compiled using /DEBUG and the image
was linked using /DSF.
8.11.3 Possible Problems You May Encounter
SET IMAGE EXEC_INIT SET MODULE/ALL SET MODULE SHARE$SYS$BASE_IMAGE |
8.12 Sample System Code Debugging Session
This section provides a sample session that shows the use of some
OpenVMS debugger commands as they apply to SCD. The examples in this
session show how to work with C code that has been linked into the
SYSTEM_DEBUG execlet. It is called as an initialization routine for
SYSTEM_DEBUG.
To reproduce this sample session, the host system needs access to the SYSTEM_DEBUG.DSF matching the SYSTEM_DEBUG.EXE file on your target system, and to the source file C_TEST_ROUTINES.C, which is available in SYS$EXAMPLES. The target system is booted with the boot flags 0, 8004, so it stops at an initial breakpoint, and the devices DKB200,ESA0.
Example 8-1 Booting the Target System |
---|
>>> b -fl 0,8004 dkb200,esa0 INIT-S-CPU... INIT-S-RESET_TC... INIT-S-ASIC... INIT-S-MEM... INIT-S-NVR... INIT-S-SCC... INIT-S-NI... INIT-S-SCSI... INIT-S-ISDN... INIT-S-TC0... AUDIT_BOOT_STARTS ... AUDIT_CHECKSUM_GOOD AUDIT_LOAD_BEGINS AUDIT_LOAD_DONE %SYSBOOT-I-GCTFIL, Using a configuration file to boot as a Galaxy instance. OpenVMS (TM) Alpha Operating System, Version V7.2 DBGTK: Initialization succeeded. Remote system debugging is now possible. DBGTK: Waiting at breakpoint for connection from remote host. |
The example continues by invoking the system code debugger's character cell interface on the host system.
Example 8-2 Invoking the System Code Debugger |
---|
$ define dbg$decw$display " " $ debug/keep OpenVMS Alpha Debug64 Version V7.2-019 DBG> |
Use the CONNECT command to connect to the target system. In this example, the target system's default password is the null string, and the logical name DBGHK$IMAGE_PATH is used for the image path; so the command qualifiers /PASSWORD and /IMAGE_PATH are not being used. You may need to use them.
When you have connected to the target system, the DEBUG prompt is displayed. Enter the SHOW IMAGE command to see what has been loaded. Because you are reaching a breakpoint early in the boot process, there are very few images. See Example 8-3. Notice that SYS$BASE_IMAGE has an asterisk next to it. This is the currently set image, and all symbols currently loaded in the debugger come from that image.
Example 8-3 Connecting to the Target System |
---|
DBG> connect %node_name TSTSYS %DEBUG-I-INIBRK, target system interrupted %DEBUG-I-DYNMODSET, setting module SYSTEM_ROUTINES DBG> show image image name set base address end address ERRORLOG no 0000000000000000 FFFFFFFFFFFFFFFF NPRO0 FFFFFFFF80084000 FFFFFFFF80086FFF NPRW1 FFFFFFFF80CA3600 FFFFFFFF80CA3BFF EXEC_INIT no FFFFFFFF8306E000 FFFFFFFF830A2000 *SYS$BASE_IMAGE yes 0000000000000000 FFFFFFFFFFFFFFFF NPRO0 FFFFFFFF80002000 FFFFFFFF8000EDFF NPRW1 FFFFFFFF80C05C00 FFFFFFFF80C2AFFF SYS$CNBTDRIVER no 0000000000000000 FFFFFFFFFFFFFFFF NPRO0 FFFFFFFF8001A000 FFFFFFFF8001AFFF NPRW1 FFFFFFFF80C2D600 FFFFFFFF80C2D9FF SYS$CPU_ROUTINES_0402 no 0000000000000000 FFFFFFFFFFFFFFFF NPRO0 FFFFFFFF80010000 FFFFFFFF800191FF NPRW1 FFFFFFFF80C2B000 FFFFFFFF80C2D5FF SYS$ESBTDRIVER no 0000000000000000 FFFFFFFFFFFFFFFF NPRO0 FFFFFFFF8002C000 FFFFFFFF8002E1FF NPRW1 FFFFFFFF80C30C00 FFFFFFFF80C30FFF SYS$NISCA_BTDRIVER no 0000000000000000 FFFFFFFFFFFFFFFF NPRO0 FFFFFFFF8001C000 FFFFFFFF8002ADFF NPRW1 FFFFFFFF80C2DA00 FFFFFFFF80C30BFF SYS$OPDRIVER no 0000000000000000 FFFFFFFFFFFFFFFF NPRO0 FFFFFFFF80030000 FFFFFFFF800337FF NPRW1 FFFFFFFF80C31000 FFFFFFFF80C319FF SYS$PUBLIC_VECTORS no 0000000000000000 FFFFFFFFFFFFFFFF NPRO0 FFFFFFFF80000000 FFFFFFFF80001FFF NPRW1 FFFFFFFF80C00000 FFFFFFFF80C05BFF SYSTEM_DEBUG no FFFFFFFF82FFE000 FFFFFFFF83056000 SYSTEM_PRIMITIVES_MIN no 0000000000000000 FFFFFFFFFFFFFFFF NPRO0 FFFFFFFF80034000 FFFFFFFF800775FF NPRW1 FFFFFFFF80C31A00 FFFFFFFF80CA11FF SYSTEM_SYNCHRONIZATION_UNI no 0000000000000000 FFFFFFFFFFFFFFFF NPRO0 FFFFFFFF80078000 FFFFFFFF800835FF NPRW1 FFFFFFFF80CA1200 FFFFFFFF80CA35FF total images: 12 bytes allocated: 1517736 |
Example 8-4 shows the target system's console display during the connect sequence. Note that for security reasons, the name of the host system, the user's name, and process ID are displayed.
Example 8-4 Target System Connection Display |
---|
DBGTK: Connection attempt from host HSTSYS user GUEST process 2E801C2F DBGTK: Connection attempt succeeded |
To set a breakpoint at the first routine in the C_TEST_ROUTINES module of the SYSTEM_DEBUG.EXE execlet, do the following:
Example 8-5 Setting a Breakpoint |
---|
DBG> set image system_debug DBG> show module module name symbols language size AUX_TARGET no C 15928 BUFSRV_TARGET no C 11288 BUGCHECK_CODES no BLISS 26064 CRTLPRINTF no C 29920 C_TEST_ROUTINES no C 3808 FATAL_EXC no C 1592 HIGH_ADDRESS no C 372 LIB$CALLING_STANDARD_AUX no MACRO64 1680 LINMGR_TARGET no C 13320 LOW_ADDRESS no C 368 OBJMGR no C 5040 PLUMGR no C 19796 POOL no C 116 PROTOMGR_TARGET no C 17868 SOCMGR no C 3324 SYS$DOINIT no AMACRO 81740 TARGET_KERNEL no C 207244 TMRMGR_TARGET no C 3516 XDELTA no BLISS 189940 XDELTA_ISRS no MACRO64 2428 total modules: 20. bytes allocated: 1585168. DBG> set module c_test_routines DBG> show module c_test_routines module name symbols size C_TEST_ROUTINES yes 3808 total C modules: 1. bytes allocated: 1592264. DBG> set language c DBG> show symbol test_c_code* routine C_TEST_ROUTINES\test_c_code5 routine C_TEST_ROUTINES\test_c_code4 routine C_TEST_ROUTINES\test_c_code3 routine C_TEST_ROUTINES\test_c_code2 routine C_TEST_ROUTINES\test_c_code DBG> set break test_c_code |
Now that the breakpoint is set, you can proceed and activate the breakpoint. When that occurs, the debugger tries to open the source code for that location in the same place as where the module was compiled. Because that is not the same place as on your system, you need to tell the debugger where to find the source code. This is done with the debugger's SET SOURCE command, which takes a search list as a parameter so you can make it point to many places.
Example 8-6 Finding the Source Code |
---|
DBG> set source/latest sys$examples,sys$library DBG> go break at routine C_TEST_ROUTINES\test_c_code 166: x = xdt$fregsav[0]; |
Now that the debugger has access to the source, you can put the debugger into screen mode to see exactly where you are and the code surrounding it.
Example 8-7 Using the Set Mode Screen Command |
---|
DBG> Set Mode Screen; Set Step Nosource - SRC: module C_TEST_ROUTINES -scroll-source------------------------------------ 151: xdt$fregsav[5] = in64; 152: xdt$fregsav[6] = in32; 153: if (xdt$fregsav[9] > 0) 154: *pVar = (*pVar + xdt$fregsav[17])%xdt$fregsav[9]; 155: else 156: *pVar = (*pVar + xdt$fregsav[17]); 157: xdt$fregsav[7] = test_c_code3(10); 158: xdt$fregsav[3] = test; 159: return xdt$fregsav[23]; 160: } 161: void test_c_code(void) 162: { 163: int x,y; 164: int64 x64,y64; 165: -> 166: x = xdt$fregsav[0]; 167: y = xdt$fregsav[1]; 168: x64 = xdt$fregsav[2]; 169: y64 = xdt$fregsav[3]; 170: xdt$fregsav[14] = test_c_code2(x64+y64,x+y,x64+x,&y64); 171: test_c_code4(); 172: return; 173: } - OUT -output------------------------------------------------------------------- - PROMPT -error-program-prompt-------------------------------------------------- DBG> |
Now, you want to set another breakpoint inside the test_c_code3 routine. You use the debugger's SCROLL/UP command (8 on the keypad) to move to that routine and see that line 146 would be a good place to set the breakpoint. It is at a recursive call. Then you proceed to that breakpoint with the GO command.
Example 8-8 Using the SCROLL/UP DEBUG Command |
---|
- SRC: module C_TEST_ROUTINES -scroll-source------------------------------------ 133: void test_c_code4(void) 134: { 135: int i,k; 136: for(k=0;k<1000;k++) 137: { 138: test_c_code5(&i); 139: } 140: return; 141: } 142: int test_c_code3(int subrtnCount) 143: { 144: subrtnCount = subrtnCount - 1; 145: if (subrtnCount != 0) 146: subrtnCount = test_c_code3(subrtnCount); 147: return subrtnCount; 148: } 149: int test_c_code2(int64 in64,int in32, int64 test, int64* pVar) 150: { 151: xdt$fregsav[5] = in64; 152: xdt$fregsav[6] = in32; 153: if (xdt$fregsav[9] > 0) 154: *pVar = (*pVar + xdt$fregsav[17])%xdt$fregsav[9]; 155: else - OUT -output------------------------------------------------------------------- - PROMPT -error-program-prompt-------------------------------------------------- DBG> Scroll/Up DBG> set break %line 146 DBG> go DBG> |
When you reach that breakpoint, the source code display is updated to show where you currently are, which is indicated by an arrow. A message also appears in the OUT display indicating you reach the breakpoint at that line.
Example 8-9 Breakpoint Display |
---|
- SRC: module C_TEST_ROUTINES -scroll-source------------------------------------ 135: int i,k; 136: for(k=0;k<1000;k++) 137: { 138: test_c_code5(&i); 139: } 140: return; 141: } 142: int test_c_code3(int subrtnCount) 143: { 144: subrtnCount = subrtnCount - 1; 145: if (subrtnCount != 0) -> 146: subrtnCount = test_c_code3(subrtnCount); 147: return subrtnCount; 148: } 149: int test_c_code2(int64 in64,int in32, int64 test, int64* pVar) 150: { 151: xdt$fregsav[5] = in64; 152: xdt$fregsav[6] = in32; 153: if (xdt$fregsav[9] > 0) 154: *pVar = (*pVar + xdt$fregsav[17])%xdt$fregsav[9]; 155: else 156: *pVar = (*pVar + xdt$fregsav[17]); 157: xdt$fregsav[7] = test_c_code3(10); - OUT -output------------------------------------------------------------------- break at C_TEST_ROUTINES\test_c_code3\%LINE 146 - PROMPT -error-program-prompt-------------------------------------------------- DBG> Scroll/Up DBG> set break %line 146 DBG> go DBG> |
Now you try the debugger's STEP command. The default behavior for STEP is STEP/OVER, unlike XDELTA and DELTA, which is STEP/INTO, so, normally you would expect to step to line 147 in the code. However, because you have a breakpoint inside test_c_code3 that is called at line 146, you will reach that event first.
Example 8-10 Using the Debug Step Command |
---|
- SRC: module C_TEST_ROUTINES -scroll-source------------------------------------ 135: int i,k; 136: for(k=0;k<1000;k++) 137: { 138: test_c_code5(&i); 139: } 140: return; 141: } 142: int test_c_code3(int subrtnCount) 143: { 144: subrtnCount = subrtnCount - 1; 145: if (subrtnCount != 0) -> 146: subrtnCount = test_c_code3(subrtnCount); 147: return subrtnCount; 148: } 149: int test_c_code2(int64 in64,int in32, int64 test, int64* pVar) 150: { 151: xdt$fregsav[5] = in64; 152: xdt$fregsav[6] = in32; 153: if (xdt$fregsav[9] > 0) 154: *pVar = (*pVar + xdt$fregsav[17])%xdt$fregsav[9]; 155: else 156: *pVar = (*pVar + xdt$fregsav[17]); 157: xdt$fregsav[7] = test_c_code3(10); - OUT -output------------------------------------------------------------------- break at C_TEST_ROUTINES\test_c_code3\%LINE 146 break at C_TEST_ROUTINES\test_c_code3\%LINE 146 - PROMPT -error-program-prompt-------------------------------------------------- DBG> DBG> set break %line 146 DBG> go DBG> Step DBG> |
Now, you try a couple of other commands, EXAMINE and SHOW CALLS. The EXAMINE command allows you to look at all the C variables. Note that the C_TEST_ROUTINES module is compiled with the /NOOPTIMIZE switch which allows access to all variables. The SHOW CALLS command shows you the call sequence from the beginning of the stack. In this case, you started out in the image EXEC_INIT. (The debugger prefixes all images other than the main image with SHARE$ so it shows up as SHARE$EXEC_INIT.)
Example 8-11 Using the Examine and Show Calls Commands |
---|
- SRC: module C_TEST_ROUTINES -scroll-source------------------------------------ 135: int i,k; 136: for(k=0;k<1000;k++) 137: { 138: test_c_code5(&i); 139: } 140: return; 141: } 142: int test_c_code3(int subrtnCount) 143: { 144: subrtnCount = subrtnCount - 1; 145: if (subrtnCount != 0) -> 146: subrtnCount = test_c_code3(subrtnCount); 147: return subrtnCount; 148: } 149: int test_c_code2(int64 in64,int in32, int64 test, int64* pVar) 150: { 151: xdt$fregsav[5] = in64; 152: xdt$fregsav[6] = in32; 153: if (xdt$fregsav[9] > 0) 154: *pVar = (*pVar + xdt$fregsav[17])%xdt$fregsav[9]; 155: else 156: *pVar = (*pVar + xdt$fregsav[17]); 157: xdt$fregsav[7] = test_c_code3(10); - OUT -output------------------------------------------------------------------- break at C_TEST_ROUTINES\test_c_code3\%LINE 146 break at C_TEST_ROUTINES\test_c_code3\%LINE 146 C_TEST_ROUTINES\test_c_code3\subrtnCount: 8 module name routine name line rel PC abs PC *C_TEST_ROUTINES test_c_code3 146 00000000000000C4 FFFFFFFF83002D64 *C_TEST_ROUTINES test_c_code3 146 00000000000000D4 FFFFFFFF83002D74 *C_TEST_ROUTINES test_c_code2 157 00000000000001A0 FFFFFFFF83002E40 *C_TEST_ROUTINES test_c_code 170 0000000000000260 FFFFFFFF83002F00 *XDELTA XDT$SYSDBG_INIT 9371 0000000000000058 FFFFFFFF83052238 *SYS$DOINIT INI$DOINIT 1488 0000000000000098 FFFFFFFF830520B8 SHARE$EXEC_INIT 0000000000018C74 FFFFFFFF83086C74 SHARE$EXEC_INIT 0000000000014BD0 FFFFFFFF83082BD0 - PROMPT -error-program-prompt-------------------------------------------------- DBG> DBG> set break %line 146 DBG> go DBG> Step DBG> examine subrtnCount DBG> show calls DBG> |
Previous | Next | Contents | Index |
privacy and legal statement | ||
6549PRO_031.HTML |