![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to db.1 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Research Unix] / researchv10dc / dist / man / v3 / man1|
Return to db.1 CVS log | Up to [Research Unix] / researchv10dc / dist / man / v3 / man1 |
1.1 root 1: .pa 1
2: .he 'DB (I)'3/15/72'DB (I)'
3: .ti 0
4: NAME db -- debug
5: .sp
6: .ti 0
7: SYNOPSIS db__ [ core [ namelist ] ] [ -_ ]
8: .sp
9: .ti 0
10: DESCRIPTION Unlike
11: many debugging packages (including DEC's ODT, on
12: which db__ is loosely based) db__ is not loaded as part of the
13: core image which it is used to examine; instead it examines files.
14: Typically, the file will be either a core image produced
15: after a fault or the binary output of
16: the assembler.
17: Core____ is the file being debugged; if omitted "core" is assumed.
18: namelist________ is a file containing a symbol table.
19: If it is omitted,
20: the symbol table is obtained from the
21: file being debugged,
22: or if not there from a.out_____.
23: If no appropriate name list file
24: can be found, db__ can still be used but some of its symbolic
25: facilities become unavailable.
26:
27: For the meaning of the optional third argument, see
28: the last paragraph below.
29: .sp
30: The format for most db__ requests is an address followed
31: by a one character command.
32: .sp
33: Addresses are expressions built up as follows:
34: .sp
35: .in +6
36: .un 3
37: 1. A name has the value assigned to it
38: when the input file was assembled.
39: It may be relocatable or not depending
40: on the use of the name during the assembly.
41: .br
42: .un 3
43: .sp
44: 2. An octal number is an absolute quantity with the appropriate
45: value.
46: .br
47: .un 3
48: .sp
49: 3. A decimal number immediately followed by "." is
50: an absolute quantity with the appropriate value.
51: .br
52: .un 3
53: .sp
54: 4. An octal number immediately followed by "r" is a relocatable
55: quantity with the appropriate value.
56: .br
57: .un 3
58: .sp
59: 5. The symbol "." indicates the current pointer
60: of db__. The current pointer is set by many db__ requests.
61:
62: .ti -3
63: 6. A "*" before
64: an expression forms an expression whose value is the
65: number in the word addressed by the first expression.
66: A "*" alone is equivalent to "*.".
67:
68: .ti -3
69: 6. Expressions separated by "+" or " " (blank) are expressions
70: with value equal to the sum of the components. At most
71: one of the components may be relocatable.
72: .br
73: .un 3
74: .sp
75: 8. Expressions separated by "-" form an expression
76: with value equal to the difference to the components.
77: If the right component is relocatable, the left component
78: must be relocatable.
79: .br
80: .un 3
81: .sp
82: 9. Expressions are evaluated left to right.
83: .sp 1
84: .in -6
85: Names for registers are
86: built in:
87: .sp
88: r0 ... r5
89: sp
90: pc
91: fr0 ... fr5
92: .sp
93: These may be examined.
94: Their values are deduced from the contents
95: of the stack in a core image file. They are meaningless
96: in a file that is not a core image.
97: .sp
98: If no address is given for a command, the current address
99: (also specified by ".") is assumed. In general, "."
100: points to the last word or byte printed by db__.
101: .sp
102: There are db__ commands for examining locations
103: interpreted as octal numbers, machine instructions,
104: ASCII characters, and addresses.
105: For numbers and characters, either bytes
106: or words may be examined.
107: The following commands are used to examine the specified file.
108: .sp
109: .in +6
110: .un 3
111: / The addressed word is printed in octal.
112:
113: .un 3
114: \\ The addressed byte is printed in octal.
115:
116: .un 3
117: " The addressed word is printed as two ASCII characters.
118:
119: .un 3
120: ' The addressed byte is printed as an ASCII character.
121: .ti -3
122:
123: ` The addressed word is printed in decimal.
124:
125: .un 3
126: ? The addressed word is interpreted as a machine
127: instruction and a symbolic form of the instruction,
128: including symbolic addresses, is printed.
129: Often, the result will appear exactly as it was written
130: in the source program.
131: .br
132: .un 3
133:
134: & The addressed word is interpreted as a symbolic address
135: and is printed as the name of the symbol whose value is closest
136: to the addressed word, possibly followed by a signed offset.
137: .br
138: .un 3
139:
140: <nl> (i. e., the character "new line") This command advances
141: the current location counter "." and prints the resulting
142: location in the mode last specified by
143: one of the above requests.
144: .br
145: .un 3
146:
147: ^ This character decrements "." and prints the
148: resulting location in the mode last selected
149: one of the above requests. It is a converse to <nl>.
150:
151: .un 3
152: % Exit.
153: .sp
154: .in -6
155: Odd addresses to word-oriented commands are rounded
156: down.
157: The incrementing and decrementing
158: of "." done by the <nl> and ^ requests is by one or
159: two depending on whether the last command
160: was word or byte oriented.
161: .sp
162: The address portion of any of the above commands
163: may be followed by a comma and then by an
164: expression. In this case that number of sequential
165: words or bytes specified by the expression is printed.
166: "." is advanced so that it points at the
167: last thing printed.
168: .sp
169: There are two commands to interpret the value
170: of expressions.
171: .sp
172: .in +6
173: .un 3
174: = When preceded by an expression, the value of the expression
175: is typed in octal.
176: When not preceded by an expression, the value of "." is
177: indicated.
178: This command does not change the value of ".".
179: .br
180: .un 3
181:
182: : An attempt is made to print the given expression
183: as a symbolic address. If the expression is relocatable,
184: that symbol is found whose value is nearest
185: that of the expression, and the symbol is typed, followed by
186: a sign and the appropriate offset.
187: If the value of the expression is absolute, a symbol
188: with exactly the indicated value is sought and
189: printed if found; if no matching symbol is discovered, the
190: octal value of the expression is given.
191: .sp
192: .in -6
193: The following command may be used to patch the file being debugged.
194: .sp
195: .in +6
196: .un 3
197: ! This command must be preceded by an expression.
198: The value of the expression is stored at the location
199: addressed by the current value of ".".
200: The opcodes do not appear in the symbol
201: table, so the user must assemble them by hand.
202:
203: .sp
204: .in -6
205: The following command is used after a fault has caused
206: a core image file to be produced.
207: .sp
208: .in +6
209: .un 3
210: $ causes the fault type and
211: the contents of the general registers and
212: several other registers to be printed both in octal and symbolic
213: format.
214: The values are as they were at the time of the fault.
215: .sp
216: .in -6
217: Db__ should not be used to examine special files,
218: for example disks and tapes, since it reads one byte
219: at a time.
220: Use od(I) instead.
221:
222: For some purposes, it is important to know how addresses
223: typed by the user correspond with
224: locations in the file being debugged.
225: The mapping algorithm employed by db__ is non-trivial
226: for two reasons:
227: First, in an a.out_____ file, there is a 20(8) byte header
228: which will not appear when the file is loaded into
229: core for execution.
230: Therefore, apparent location 0 should correspond
231: with actual file offset 20.
232: Second, some systems cause a "squashed" core
233: image to be written.
234: In such a core
235: image, addresses in the stack must be mapped
236: according to the degree of squashing
237: which has been employed.
238: Db__ obeys the following rules:
239:
240: If exactly one argument is given, and if it appears
241: to be an a.out_____ file, the 20-byte header is skipped
242: during addressing, i.e., 20 is added to all addresses typed.
243: As a consequence, the header can be examined
244: beginning at location -20.
245:
246: If exactly one argument is given and if the file does
247: not appear to be an a.out_____ file, no mapping is done.
248:
249: If zero or two arguments are given,
250: the mapping appropriate to a core image file is employed.
251: This means that locations above the program break
252: and below the stack
253: effectively do not exist (and are not, in fact, recorded
254: in the core file).
255: Locations above the user's stack pointer are mapped,
256: in looking at the core file, to
257: the place where they are really stored.
258: The per-process data kept by the
259: system, which is stored in the last 512(10) bytes
260: of the core file,
261: can be addressed at apparent locations 160000-160777.
262:
263: If one wants to examine
264: a file which has an associated name list,
265: but is not a core image file, the last argument "-"
266: can be used (actually the only purpose of the
267: last argument is to make the number of
268: arguments not equal to two).
269: This feature is used most frequently in
270: examining the memory file /dev/mem.
271:
272: .ti 0
273: FILES --
274: .sp
275: .ti 0
276: SEE ALSO as(I), core(V), a.out(V), od(I)
277: .sp
278: .ti 0
279: DIAGNOSTICS "File not found" if the first argument
280: cannot be read; otherwise "?".
281: .sp
282: .ti 0
283: BUGS --
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.