Intel XENIX 286 Programmers Guide (86) - Tenox.tc
Intel XENIX 286 Programmers Guide (86) - Tenox.tc Intel XENIX 286 Programmers Guide (86) - Tenox.tc
APPENDIX B PROG RAMMING COMMANDS This section describes the programming commands available in the XENIX 286 Extended System product. Syntax Unless otherwise noted, commands described in this section accept options and other arguments according to the following syntax: name option cmdarg name [option ] ... [ cmdarg] ... The file name or path name of an executable file. A single letter representing a command option. By convention, most options are preceded by a hyphen. Option letters can sometimes be grouped together, as in -abed. Alternatively they are specified individually, as in -a -b -c -d. The method of specifying options depends on the syntax of the command. Some options require argu ments. For example, the -f option for many commands often takes a following file name argument. A path name or other command argument not beginning with a hyphen. It may also be a hyphen alone by itself, indicating the standard input. Note: Not all commands adhere to the above syntax. See Also getopt in "Commands" in the XENIX 286 Reference Manual getopt in "System Functions" in the XENIX 286 C Library Guide Diagnostics Upon termination, each command returns 2 bytes of status, one supplied by the system and giving the cause for termination, and (in the case of "normal" termination) one supplied by the program. (See wait and exit in "System Functions" in the XENIX 286 C Library Guide.) The byte supplied by the system is zero for normal termination; the byte supplied by the program is customarily zero to indicate successful execution and nonzero to indicate troubles such as erroneous parameters or bad or inaccessible data. It is called variously "exit code," "exit status," or "return code," and is described only where special conventions are involved. B- 1
Programming Commands XENIX Programming ad b - Invokes a general-purpose debugger. Syntax adb [ -w 1 [ -p prompt 1 [ objfil [ corefile 1 1 Description A general-purpose debugging program, adb may be used to examine files and to provide a controlled environment for the execution of XENIX programs. Normally an executable program file, objfil preferably contains a sym bol table; if not, then the symbolic features of adb cannot be used, although the file can still be examined. The default for objfil is a.out. corefile is assumed to be a core image file produced after executing objfil. The default for corefile is core. Requests to adb are read from the standard input, and responses are written to the standard output. If the -w option is present, then both objfil and corefiZe are created if necessary and opened for reading and writing so that files can be modified with adb. The QUIT and INTERRUPT keys cause adb to return to the next command. The -p option defines the prompt string. It may be any combination of characters. The default is an asterisk (*). In general requests to adb are of the form [ address 1 [, count 1 [ command 1 [ ; 1 If address is present, then dot is set to address. Initially, dot is set to zero. For most commands, count specifies how many times the command will be executed. The default count is 1. A special expression, address has the form [segment: 1 offset where segment gives the address of a specific text or data segment, and offset gives an offset from the beginning of that segment. If segment is not specified, then the last segment value in a command is used. The interpretation of an address depends on the context it is used in. If a subprocess is being debugged, then addresses are interpreted in the usual way in the address space of the subprocess. For details on address mapping, see the "Addresses" section later in this entry. B-2
- Page 214 and 215: XENIX Programming yacc: Compiler-Co
- Page 216 and 217: XENIX Programming yacc: Compiler-Co
- Page 218 and 219: XENIX Programming yacc: Compiler-Co
- Page 220 and 221: XENIX Programming yacc: Compiler-Co
- Page 222 and 223: XENIX Programming yacc: Compiler-Co
- Page 224 and 225: XENIX Programming yacc: Compiler-Co
- Page 226 and 227: XENIX Programming yacc: Compiler-Co
- Page 228 and 229: XENIX Programming yacc: Compiler-Co
- Page 230 and 231: XENIX Programming yacc: Compiler-Co
- Page 232 and 233: XENIX Programming yacc: Compiler-Co
- Page 234 and 235: XENIX Programming yacc: Compiler-Co
- Page 236 and 237: XENIX Programming %left %left %left
- Page 238 and 239: XENIX Programming I* lexical analys
- Page 240: XENIX Programming yacc: Compiler-Co
- Page 243 and 244: m4: Macro Processor XENIX Programmi
- Page 245 and 246: m4: Macro Processor XENIX Programmi
- Page 247 and 248: m4: Macro Processor XENIX Programm
- Page 249 and 250: m4: Macro Processor XENIX Programmi
- Page 251 and 252: m4: Macro Processor XENIX Programmi
- Page 253 and 254: C Language Portability XENIX Progra
- Page 255 and 256: C Language Portability XENIX Progra
- Page 257 and 258: C Language Portability XENIX Progra
- Page 259 and 260: C Language Portability XENIX Progra
- Page 261 and 262: C Language Portability XENIX Progra
- Page 263 and 264: C Language Portability XENIX Progra
- Page 268 and 269: XENIX Programming ad b (continued)
- Page 270 and 271: XENIX Programming Programming Comma
- Page 272 and 273: XENIX Programming Programming Comma
- Page 274 and 275: XENIX Programming Programming Comma
- Page 276 and 277: XENIX Programming Programming Comma
- Page 278 and 279: XENIX Programming Programming Comma
- Page 280 and 281: XENIX Programming Programming Comma
- Page 282 and 283: XENIX Programming Programming Comma
- Page 284 and 285: XENIX Programming as (continued) Fi
- Page 286 and 287: XENIX Programming Programming Comma
- Page 288 and 289: XENIX Programming Programming Comma
- Page 290 and 291: XENIX Programming Programm ing Comm
- Page 292 and 293: XENIX Programming Programming Comma
- Page 294 and 295: XENIX Programming Programming Comma
- Page 296 and 297: XENIX Programming Programm ing Comm
- Page 298 and 299: XENIX Programming Programming Comma
- Page 300 and 301: XENIX Programming Programming Comma
- Page 302 and 303: XENIX Programming Programming Comma
- Page 304 and 305: XENIX Programming Programming Comma
- Page 306 and 307: XENIX Programming Programming Comma
- Page 308 and 309: XENIX Programming Programming Comma
- Page 310 and 311: XENIX Programming Programming Comma
- Page 312 and 313: XENIX Programming Programming Comma
- Page 314 and 315: XENIX Programm ing Programming Comm
Programming Commands <strong>XENIX</strong> Programming<br />
ad b - Invokes a general-purpose debugger.<br />
Syntax<br />
adb [ -w 1 [ -p prompt 1 [ objfil [ corefile 1 1<br />
Description<br />
A general-purpose debugging program, adb may be used to examine files and to provide<br />
a controlled environment for the execution of <strong>XENIX</strong> programs.<br />
Normally an executable program file, objfil preferably contains a sym bol table; if not,<br />
then the symbolic features of adb cannot be used, although the file can still be<br />
examined. The default for objfil is a.out. corefile is assumed to be a core image file<br />
produced after executing objfil. The default for corefile is core.<br />
Requests to adb are read from the standard input, and responses are written to the<br />
standard output. If the -w option is present, then both objfil and corefiZe are created if<br />
necessary and opened for reading and writing so that files can be modified with adb.<br />
The QUIT and INTERRUPT keys cause adb to return to the next command. The -p<br />
option defines the prompt string. It may be any combination of characters. The default<br />
is an asterisk (*).<br />
In general requests to adb are of the form<br />
[ address 1 [, count 1 [ command 1 [ ; 1<br />
If address is present, then dot is set to address. Initially, dot is set to zero. For most<br />
commands, count specifies how many times the command will be executed. The default<br />
count is 1. A special expression, address has the form<br />
[segment: 1 offset<br />
where segment gives the address of a specific text or data segment, and offset gives an<br />
offset from the beginning of that segment. If segment is not specified, then the last<br />
segment value in a command is used.<br />
The interpretation of an address depends on the context it is used in. If a subprocess is<br />
being debugged, then addresses are interpreted in the usual way in the address space of<br />
the subprocess. For details on address mapping, see the "Addresses" section later in this<br />
entry.<br />
B-2