1 |
1181 |
sfurman |
This is gdbint.info, produced by makeinfo version 4.1 from
|
2 |
|
|
./gdbint.texinfo.
|
3 |
|
|
|
4 |
|
|
INFO-DIR-SECTION Programming & development tools.
|
5 |
|
|
START-INFO-DIR-ENTRY
|
6 |
|
|
* Gdb-Internals: (gdbint). The GNU debugger's internals.
|
7 |
|
|
END-INFO-DIR-ENTRY
|
8 |
|
|
|
9 |
|
|
This file documents the internals of the GNU debugger GDB.
|
10 |
|
|
Copyright 1990,1991,1992,1993,1994,1996,1998,1999,2000,2001,2002
|
11 |
|
|
Free Software Foundation, Inc. Contributed by Cygnus Solutions.
|
12 |
|
|
Written by John Gilmore. Second Edition by Stan Shebs.
|
13 |
|
|
|
14 |
|
|
Permission is granted to copy, distribute and/or modify this document
|
15 |
|
|
under the terms of the GNU Free Documentation License, Version 1.1 or
|
16 |
|
|
any later version published by the Free Software Foundation; with no
|
17 |
|
|
Invariant Sections, with the Front-Cover Texts being "A GNU Manual,"
|
18 |
|
|
and with the Back-Cover Texts as in (a) below.
|
19 |
|
|
|
20 |
|
|
(a) The FSF's Back-Cover Text is: "You have freedom to copy and
|
21 |
|
|
modify this GNU Manual, like GNU software. Copies published by the Free
|
22 |
|
|
Software Foundation raise funds for GNU development."
|
23 |
|
|
|
24 |
|
|
|
25 |
|
|
File: gdbint.info, Node: Top, Next: Requirements, Up: (dir)
|
26 |
|
|
|
27 |
|
|
Scope of this Document
|
28 |
|
|
**********************
|
29 |
|
|
|
30 |
|
|
This document documents the internals of the GNU debugger, GDB. It
|
31 |
|
|
includes description of GDB's key algorithms and operations, as well as
|
32 |
|
|
the mechanisms that adapt GDB to specific hosts and targets.
|
33 |
|
|
|
34 |
|
|
* Menu:
|
35 |
|
|
|
36 |
|
|
* Requirements::
|
37 |
|
|
* Overall Structure::
|
38 |
|
|
* Algorithms::
|
39 |
|
|
* User Interface::
|
40 |
|
|
* libgdb::
|
41 |
|
|
* Symbol Handling::
|
42 |
|
|
* Language Support::
|
43 |
|
|
* Host Definition::
|
44 |
|
|
* Target Architecture Definition::
|
45 |
|
|
* Target Vector Definition::
|
46 |
|
|
* Native Debugging::
|
47 |
|
|
* Support Libraries::
|
48 |
|
|
* Coding::
|
49 |
|
|
* Porting GDB::
|
50 |
|
|
* Releasing GDB::
|
51 |
|
|
* Testsuite::
|
52 |
|
|
* Hints::
|
53 |
|
|
|
54 |
|
|
* GNU Free Documentation License:: The license for this documentation
|
55 |
|
|
* Index::
|
56 |
|
|
|
57 |
|
|
|
58 |
|
|
File: gdbint.info, Node: Requirements, Next: Overall Structure, Prev: Top, Up: Top
|
59 |
|
|
|
60 |
|
|
Requirements
|
61 |
|
|
************
|
62 |
|
|
|
63 |
|
|
Before diving into the internals, you should understand the formal
|
64 |
|
|
requirements and other expectations for GDB. Although some of these
|
65 |
|
|
may seem obvious, there have been proposals for GDB that have run
|
66 |
|
|
counter to these requirements.
|
67 |
|
|
|
68 |
|
|
First of all, GDB is a debugger. It's not designed to be a front
|
69 |
|
|
panel for embedded systems. It's not a text editor. It's not a shell.
|
70 |
|
|
It's not a programming environment.
|
71 |
|
|
|
72 |
|
|
GDB is an interactive tool. Although a batch mode is available,
|
73 |
|
|
GDB's primary role is to interact with a human programmer.
|
74 |
|
|
|
75 |
|
|
GDB should be responsive to the user. A programmer hot on the trail
|
76 |
|
|
of a nasty bug, and operating under a looming deadline, is going to be
|
77 |
|
|
very impatient of everything, including the response time to debugger
|
78 |
|
|
commands.
|
79 |
|
|
|
80 |
|
|
GDB should be relatively permissive, such as for expressions. While
|
81 |
|
|
the compiler should be picky (or have the option to be made picky),
|
82 |
|
|
since source code lives for a long time usually, the programmer doing
|
83 |
|
|
debugging shouldn't be spending time figuring out to mollify the
|
84 |
|
|
debugger.
|
85 |
|
|
|
86 |
|
|
GDB will be called upon to deal with really large programs.
|
87 |
|
|
Executable sizes of 50 to 100 megabytes occur regularly, and we've
|
88 |
|
|
heard reports of programs approaching 1 gigabyte in size.
|
89 |
|
|
|
90 |
|
|
GDB should be able to run everywhere. No other debugger is
|
91 |
|
|
available for even half as many configurations as GDB supports.
|
92 |
|
|
|
93 |
|
|
|
94 |
|
|
File: gdbint.info, Node: Overall Structure, Next: Algorithms, Prev: Requirements, Up: Top
|
95 |
|
|
|
96 |
|
|
Overall Structure
|
97 |
|
|
*****************
|
98 |
|
|
|
99 |
|
|
GDB consists of three major subsystems: user interface, symbol
|
100 |
|
|
handling (the "symbol side"), and target system handling (the "target
|
101 |
|
|
side").
|
102 |
|
|
|
103 |
|
|
The user interface consists of several actual interfaces, plus
|
104 |
|
|
supporting code.
|
105 |
|
|
|
106 |
|
|
The symbol side consists of object file readers, debugging info
|
107 |
|
|
interpreters, symbol table management, source language expression
|
108 |
|
|
parsing, type and value printing.
|
109 |
|
|
|
110 |
|
|
The target side consists of execution control, stack frame analysis,
|
111 |
|
|
and physical target manipulation.
|
112 |
|
|
|
113 |
|
|
The target side/symbol side division is not formal, and there are a
|
114 |
|
|
number of exceptions. For instance, core file support involves symbolic
|
115 |
|
|
elements (the basic core file reader is in BFD) and target elements (it
|
116 |
|
|
supplies the contents of memory and the values of registers). Instead,
|
117 |
|
|
this division is useful for understanding how the minor subsystems
|
118 |
|
|
should fit together.
|
119 |
|
|
|
120 |
|
|
The Symbol Side
|
121 |
|
|
===============
|
122 |
|
|
|
123 |
|
|
The symbolic side of GDB can be thought of as "everything you can do
|
124 |
|
|
in GDB without having a live program running". For instance, you can
|
125 |
|
|
look at the types of variables, and evaluate many kinds of expressions.
|
126 |
|
|
|
127 |
|
|
The Target Side
|
128 |
|
|
===============
|
129 |
|
|
|
130 |
|
|
The target side of GDB is the "bits and bytes manipulator".
|
131 |
|
|
Although it may make reference to symbolic info here and there, most of
|
132 |
|
|
the target side will run with only a stripped executable available--or
|
133 |
|
|
even no executable at all, in remote debugging cases.
|
134 |
|
|
|
135 |
|
|
Operations such as disassembly, stack frame crawls, and register
|
136 |
|
|
display, are able to work with no symbolic info at all. In some cases,
|
137 |
|
|
such as disassembly, GDB will use symbolic info to present addresses
|
138 |
|
|
relative to symbols rather than as raw numbers, but it will work either
|
139 |
|
|
way.
|
140 |
|
|
|
141 |
|
|
Configurations
|
142 |
|
|
==============
|
143 |
|
|
|
144 |
|
|
"Host" refers to attributes of the system where GDB runs. "Target"
|
145 |
|
|
refers to the system where the program being debugged executes. In
|
146 |
|
|
most cases they are the same machine, in which case a third type of
|
147 |
|
|
"Native" attributes come into play.
|
148 |
|
|
|
149 |
|
|
Defines and include files needed to build on the host are host
|
150 |
|
|
support. Examples are tty support, system defined types, host byte
|
151 |
|
|
order, host float format.
|
152 |
|
|
|
153 |
|
|
Defines and information needed to handle the target format are target
|
154 |
|
|
dependent. Examples are the stack frame format, instruction set,
|
155 |
|
|
breakpoint instruction, registers, and how to set up and tear down the
|
156 |
|
|
stack to call a function.
|
157 |
|
|
|
158 |
|
|
Information that is only needed when the host and target are the
|
159 |
|
|
same, is native dependent. One example is Unix child process support;
|
160 |
|
|
if the host and target are not the same, doing a fork to start the
|
161 |
|
|
target process is a bad idea. The various macros needed for finding the
|
162 |
|
|
registers in the `upage', running `ptrace', and such are all in the
|
163 |
|
|
native-dependent files.
|
164 |
|
|
|
165 |
|
|
Another example of native-dependent code is support for features that
|
166 |
|
|
are really part of the target environment, but which require `#include'
|
167 |
|
|
files that are only available on the host system. Core file handling
|
168 |
|
|
and `setjmp' handling are two common cases.
|
169 |
|
|
|
170 |
|
|
When you want to make GDB work "native" on a particular machine, you
|
171 |
|
|
have to include all three kinds of information.
|
172 |
|
|
|
173 |
|
|
|
174 |
|
|
File: gdbint.info, Node: Algorithms, Next: User Interface, Prev: Overall Structure, Up: Top
|
175 |
|
|
|
176 |
|
|
Algorithms
|
177 |
|
|
**********
|
178 |
|
|
|
179 |
|
|
GDB uses a number of debugging-specific algorithms. They are often
|
180 |
|
|
not very complicated, but get lost in the thicket of special cases and
|
181 |
|
|
real-world issues. This chapter describes the basic algorithms and
|
182 |
|
|
mentions some of the specific target definitions that they use.
|
183 |
|
|
|
184 |
|
|
Frames
|
185 |
|
|
======
|
186 |
|
|
|
187 |
|
|
A frame is a construct that GDB uses to keep track of calling and
|
188 |
|
|
called functions.
|
189 |
|
|
|
190 |
|
|
`FRAME_FP' in the machine description has no meaning to the
|
191 |
|
|
machine-independent part of GDB, except that it is used when setting up
|
192 |
|
|
a new frame from scratch, as follows:
|
193 |
|
|
|
194 |
|
|
create_new_frame (read_register (FP_REGNUM), read_pc ()));
|
195 |
|
|
|
196 |
|
|
Other than that, all the meaning imparted to `FP_REGNUM' is imparted
|
197 |
|
|
by the machine-dependent code. So, `FP_REGNUM' can have any value that
|
198 |
|
|
is convenient for the code that creates new frames.
|
199 |
|
|
(`create_new_frame' calls `INIT_EXTRA_FRAME_INFO' if it is defined;
|
200 |
|
|
that is where you should use the `FP_REGNUM' value, if your frames are
|
201 |
|
|
nonstandard.)
|
202 |
|
|
|
203 |
|
|
Given a GDB frame, define `FRAME_CHAIN' to determine the address of
|
204 |
|
|
the calling function's frame. This will be used to create a new GDB
|
205 |
|
|
frame struct, and then `INIT_EXTRA_FRAME_INFO' and `INIT_FRAME_PC' will
|
206 |
|
|
be called for the new frame.
|
207 |
|
|
|
208 |
|
|
Breakpoint Handling
|
209 |
|
|
===================
|
210 |
|
|
|
211 |
|
|
In general, a breakpoint is a user-designated location in the program
|
212 |
|
|
where the user wants to regain control if program execution ever reaches
|
213 |
|
|
that location.
|
214 |
|
|
|
215 |
|
|
There are two main ways to implement breakpoints; either as
|
216 |
|
|
"hardware" breakpoints or as "software" breakpoints.
|
217 |
|
|
|
218 |
|
|
Hardware breakpoints are sometimes available as a builtin debugging
|
219 |
|
|
features with some chips. Typically these work by having dedicated
|
220 |
|
|
register into which the breakpoint address may be stored. If the PC
|
221 |
|
|
(shorthand for "program counter") ever matches a value in a breakpoint
|
222 |
|
|
registers, the CPU raises an exception and reports it to GDB.
|
223 |
|
|
|
224 |
|
|
Another possibility is when an emulator is in use; many emulators
|
225 |
|
|
include circuitry that watches the address lines coming out from the
|
226 |
|
|
processor, and force it to stop if the address matches a breakpoint's
|
227 |
|
|
address.
|
228 |
|
|
|
229 |
|
|
A third possibility is that the target already has the ability to do
|
230 |
|
|
breakpoints somehow; for instance, a ROM monitor may do its own
|
231 |
|
|
software breakpoints. So although these are not literally "hardware
|
232 |
|
|
breakpoints", from GDB's point of view they work the same; GDB need not
|
233 |
|
|
do nothing more than set the breakpoint and wait for something to
|
234 |
|
|
happen.
|
235 |
|
|
|
236 |
|
|
Since they depend on hardware resources, hardware breakpoints may be
|
237 |
|
|
limited in number; when the user asks for more, GDB will start trying
|
238 |
|
|
to set software breakpoints. (On some architectures, notably the
|
239 |
|
|
32-bit x86 platforms, GDB cannot always know whether there's enough
|
240 |
|
|
hardware resources to insert all the hardware breakpoints and
|
241 |
|
|
watchpoints. On those platforms, GDB prints an error message only when
|
242 |
|
|
the program being debugged is continued.)
|
243 |
|
|
|
244 |
|
|
Software breakpoints require GDB to do somewhat more work. The
|
245 |
|
|
basic theory is that GDB will replace a program instruction with a
|
246 |
|
|
trap, illegal divide, or some other instruction that will cause an
|
247 |
|
|
exception, and then when it's encountered, GDB will take the exception
|
248 |
|
|
and stop the program. When the user says to continue, GDB will restore
|
249 |
|
|
the original instruction, single-step, re-insert the trap, and continue
|
250 |
|
|
on.
|
251 |
|
|
|
252 |
|
|
Since it literally overwrites the program being tested, the program
|
253 |
|
|
area must be writable, so this technique won't work on programs in ROM.
|
254 |
|
|
It can also distort the behavior of programs that examine themselves,
|
255 |
|
|
although such a situation would be highly unusual.
|
256 |
|
|
|
257 |
|
|
Also, the software breakpoint instruction should be the smallest
|
258 |
|
|
size of instruction, so it doesn't overwrite an instruction that might
|
259 |
|
|
be a jump target, and cause disaster when the program jumps into the
|
260 |
|
|
middle of the breakpoint instruction. (Strictly speaking, the
|
261 |
|
|
breakpoint must be no larger than the smallest interval between
|
262 |
|
|
instructions that may be jump targets; perhaps there is an architecture
|
263 |
|
|
where only even-numbered instructions may jumped to.) Note that it's
|
264 |
|
|
possible for an instruction set not to have any instructions usable for
|
265 |
|
|
a software breakpoint, although in practice only the ARC has failed to
|
266 |
|
|
define such an instruction.
|
267 |
|
|
|
268 |
|
|
The basic definition of the software breakpoint is the macro
|
269 |
|
|
`BREAKPOINT'.
|
270 |
|
|
|
271 |
|
|
Basic breakpoint object handling is in `breakpoint.c'. However,
|
272 |
|
|
much of the interesting breakpoint action is in `infrun.c'.
|
273 |
|
|
|
274 |
|
|
Single Stepping
|
275 |
|
|
===============
|
276 |
|
|
|
277 |
|
|
Signal Handling
|
278 |
|
|
===============
|
279 |
|
|
|
280 |
|
|
Thread Handling
|
281 |
|
|
===============
|
282 |
|
|
|
283 |
|
|
Inferior Function Calls
|
284 |
|
|
=======================
|
285 |
|
|
|
286 |
|
|
Longjmp Support
|
287 |
|
|
===============
|
288 |
|
|
|
289 |
|
|
GDB has support for figuring out that the target is doing a
|
290 |
|
|
`longjmp' and for stopping at the target of the jump, if we are
|
291 |
|
|
stepping. This is done with a few specialized internal breakpoints,
|
292 |
|
|
which are visible in the output of the `maint info breakpoint' command.
|
293 |
|
|
|
294 |
|
|
To make this work, you need to define a macro called
|
295 |
|
|
`GET_LONGJMP_TARGET', which will examine the `jmp_buf' structure and
|
296 |
|
|
extract the longjmp target address. Since `jmp_buf' is target
|
297 |
|
|
specific, you will need to define it in the appropriate `tm-TARGET.h'
|
298 |
|
|
file. Look in `tm-sun4os4.h' and `sparc-tdep.c' for examples of how to
|
299 |
|
|
do this.
|
300 |
|
|
|
301 |
|
|
Watchpoints
|
302 |
|
|
===========
|
303 |
|
|
|
304 |
|
|
Watchpoints are a special kind of breakpoints (*note breakpoints:
|
305 |
|
|
Algorithms.) which break when data is accessed rather than when some
|
306 |
|
|
instruction is executed. When you have data which changes without your
|
307 |
|
|
knowing what code does that, watchpoints are the silver bullet to hunt
|
308 |
|
|
down and kill such bugs.
|
309 |
|
|
|
310 |
|
|
Watchpoints can be either hardware-assisted or not; the latter type
|
311 |
|
|
is known as "software watchpoints." GDB always uses hardware-assisted
|
312 |
|
|
watchpoints if they are available, and falls back on software
|
313 |
|
|
watchpoints otherwise. Typical situations where GDB will use software
|
314 |
|
|
watchpoints are:
|
315 |
|
|
|
316 |
|
|
* The watched memory region is too large for the underlying hardware
|
317 |
|
|
watchpoint support. For example, each x86 debug register can
|
318 |
|
|
watch up to 4 bytes of memory, so trying to watch data structures
|
319 |
|
|
whose size is more than 16 bytes will cause GDB to use software
|
320 |
|
|
watchpoints.
|
321 |
|
|
|
322 |
|
|
* The value of the expression to be watched depends on data held in
|
323 |
|
|
registers (as opposed to memory).
|
324 |
|
|
|
325 |
|
|
* Too many different watchpoints requested. (On some architectures,
|
326 |
|
|
this situation is impossible to detect until the debugged program
|
327 |
|
|
is resumed.) Note that x86 debug registers are used both for
|
328 |
|
|
hardware breakpoints and for watchpoints, so setting too many
|
329 |
|
|
hardware breakpoints might cause watchpoint insertion to fail.
|
330 |
|
|
|
331 |
|
|
* No hardware-assisted watchpoints provided by the target
|
332 |
|
|
implementation.
|
333 |
|
|
|
334 |
|
|
Software watchpoints are very slow, since GDB needs to single-step
|
335 |
|
|
the program being debugged and test the value of the watched
|
336 |
|
|
expression(s) after each instruction. The rest of this section is
|
337 |
|
|
mostly irrelevant for software watchpoints.
|
338 |
|
|
|
339 |
|
|
GDB uses several macros and primitives to support hardware
|
340 |
|
|
watchpoints:
|
341 |
|
|
|
342 |
|
|
`TARGET_HAS_HARDWARE_WATCHPOINTS'
|
343 |
|
|
If defined, the target supports hardware watchpoints.
|
344 |
|
|
|
345 |
|
|
`TARGET_CAN_USE_HARDWARE_WATCHPOINT (TYPE, COUNT, OTHER)'
|
346 |
|
|
Return the number of hardware watchpoints of type TYPE that are
|
347 |
|
|
possible to be set. The value is positive if COUNT watchpoints of
|
348 |
|
|
this type can be set, zero if setting watchpoints of this type is
|
349 |
|
|
not supported, and negative if COUNT is more than the maximum
|
350 |
|
|
number of watchpoints of type TYPE that can be set. OTHER is
|
351 |
|
|
non-zero if other types of watchpoints are currently enabled (there
|
352 |
|
|
are architectures which cannot set watchpoints of different types
|
353 |
|
|
at the same time).
|
354 |
|
|
|
355 |
|
|
`TARGET_REGION_OK_FOR_HW_WATCHPOINT (ADDR, LEN)'
|
356 |
|
|
Return non-zero if hardware watchpoints can be used to watch a
|
357 |
|
|
region whose address is ADDR and whose length in bytes is LEN.
|
358 |
|
|
|
359 |
|
|
`TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT (SIZE)'
|
360 |
|
|
Return non-zero if hardware watchpoints can be used to watch a
|
361 |
|
|
region whose size is SIZE. GDB only uses this macro as a
|
362 |
|
|
fall-back, in case `TARGET_REGION_OK_FOR_HW_WATCHPOINT' is not
|
363 |
|
|
defined.
|
364 |
|
|
|
365 |
|
|
`TARGET_DISABLE_HW_WATCHPOINTS (PID)'
|
366 |
|
|
Disables watchpoints in the process identified by PID. This is
|
367 |
|
|
used, e.g., on HP-UX which provides operations to disable and
|
368 |
|
|
enable the page-level memory protection that implements hardware
|
369 |
|
|
watchpoints on that platform.
|
370 |
|
|
|
371 |
|
|
`TARGET_ENABLE_HW_WATCHPOINTS (PID)'
|
372 |
|
|
Enables watchpoints in the process identified by PID. This is
|
373 |
|
|
used, e.g., on HP-UX which provides operations to disable and
|
374 |
|
|
enable the page-level memory protection that implements hardware
|
375 |
|
|
watchpoints on that platform.
|
376 |
|
|
|
377 |
|
|
`target_insert_watchpoint (ADDR, LEN, TYPE)'
|
378 |
|
|
`target_remove_watchpoint (ADDR, LEN, TYPE)'
|
379 |
|
|
Insert or remove a hardware watchpoint starting at ADDR, for LEN
|
380 |
|
|
bytes. TYPE is the watchpoint type, one of the possible values of
|
381 |
|
|
the enumerated data type `target_hw_bp_type', defined by
|
382 |
|
|
`breakpoint.h' as follows:
|
383 |
|
|
|
384 |
|
|
enum target_hw_bp_type
|
385 |
|
|
{
|
386 |
|
|
hw_write = 0, /* Common (write) HW watchpoint */
|
387 |
|
|
hw_read = 1, /* Read HW watchpoint */
|
388 |
|
|
hw_access = 2, /* Access (read or write) HW watchpoint */
|
389 |
|
|
hw_execute = 3 /* Execute HW breakpoint */
|
390 |
|
|
};
|
391 |
|
|
|
392 |
|
|
These two macros should return 0 for success, non-zero for failure.
|
393 |
|
|
|
394 |
|
|
`target_remove_hw_breakpoint (ADDR, SHADOW)'
|
395 |
|
|
`target_insert_hw_breakpoint (ADDR, SHADOW)'
|
396 |
|
|
Insert or remove a hardware-assisted breakpoint at address ADDR.
|
397 |
|
|
Returns zero for success, non-zero for failure. SHADOW is the
|
398 |
|
|
real contents of the byte where the breakpoint has been inserted;
|
399 |
|
|
it is generally not valid when hardware breakpoints are used, but
|
400 |
|
|
since no other code touches these values, the implementations of
|
401 |
|
|
the above two macros can use them for their internal purposes.
|
402 |
|
|
|
403 |
|
|
`target_stopped_data_address ()'
|
404 |
|
|
If the inferior has some watchpoint that triggered, return the
|
405 |
|
|
address associated with that watchpoint. Otherwise, return zero.
|
406 |
|
|
|
407 |
|
|
`DECR_PC_AFTER_HW_BREAK'
|
408 |
|
|
If defined, GDB decrements the program counter by the value of
|
409 |
|
|
`DECR_PC_AFTER_HW_BREAK' after a hardware break-point. This
|
410 |
|
|
overrides the value of `DECR_PC_AFTER_BREAK' when a breakpoint
|
411 |
|
|
that breaks is a hardware-assisted breakpoint.
|
412 |
|
|
|
413 |
|
|
`HAVE_STEPPABLE_WATCHPOINT'
|
414 |
|
|
If defined to a non-zero value, it is not necessary to disable a
|
415 |
|
|
watchpoint to step over it.
|
416 |
|
|
|
417 |
|
|
`HAVE_NONSTEPPABLE_WATCHPOINT'
|
418 |
|
|
If defined to a non-zero value, GDB should disable a watchpoint to
|
419 |
|
|
step the inferior over it.
|
420 |
|
|
|
421 |
|
|
`HAVE_CONTINUABLE_WATCHPOINT'
|
422 |
|
|
If defined to a non-zero value, it is possible to continue the
|
423 |
|
|
inferior after a watchpoint has been hit.
|
424 |
|
|
|
425 |
|
|
`CANNOT_STEP_HW_WATCHPOINTS'
|
426 |
|
|
If this is defined to a non-zero value, GDB will remove all
|
427 |
|
|
watchpoints before stepping the inferior.
|
428 |
|
|
|
429 |
|
|
`STOPPED_BY_WATCHPOINT (WAIT_STATUS)'
|
430 |
|
|
Return non-zero if stopped by a watchpoint. WAIT_STATUS is of the
|
431 |
|
|
type `struct target_waitstatus', defined by `target.h'.
|
432 |
|
|
|
433 |
|
|
x86 Watchpoints
|
434 |
|
|
---------------
|
435 |
|
|
|
436 |
|
|
The 32-bit Intel x86 (a.k.a. ia32) processors feature special debug
|
437 |
|
|
registers designed to facilitate debugging. GDB provides a generic
|
438 |
|
|
library of functions that x86-based ports can use to implement support
|
439 |
|
|
for watchpoints and hardware-assisted breakpoints. This subsection
|
440 |
|
|
documents the x86 watchpoint facilities in GDB.
|
441 |
|
|
|
442 |
|
|
To use the generic x86 watchpoint support, a port should do the
|
443 |
|
|
following:
|
444 |
|
|
|
445 |
|
|
* Define the macro `I386_USE_GENERIC_WATCHPOINTS' somewhere in the
|
446 |
|
|
target-dependent headers.
|
447 |
|
|
|
448 |
|
|
* Include the `config/i386/nm-i386.h' header file _after_ defining
|
449 |
|
|
`I386_USE_GENERIC_WATCHPOINTS'.
|
450 |
|
|
|
451 |
|
|
* Add `i386-nat.o' to the value of the Make variable `NATDEPFILES'
|
452 |
|
|
(*note NATDEPFILES: Native Debugging.) or `TDEPFILES' (*note
|
453 |
|
|
TDEPFILES: Target Architecture Definition.).
|
454 |
|
|
|
455 |
|
|
* Provide implementations for the `I386_DR_LOW_*' macros described
|
456 |
|
|
below. Typically, each macro should call a target-specific
|
457 |
|
|
function which does the real work.
|
458 |
|
|
|
459 |
|
|
The x86 watchpoint support works by maintaining mirror images of the
|
460 |
|
|
debug registers. Values are copied between the mirror images and the
|
461 |
|
|
real debug registers via a set of macros which each target needs to
|
462 |
|
|
provide:
|
463 |
|
|
|
464 |
|
|
`I386_DR_LOW_SET_CONTROL (VAL)'
|
465 |
|
|
Set the Debug Control (DR7) register to the value VAL.
|
466 |
|
|
|
467 |
|
|
`I386_DR_LOW_SET_ADDR (IDX, ADDR)'
|
468 |
|
|
Put the address ADDR into the debug register number IDX.
|
469 |
|
|
|
470 |
|
|
`I386_DR_LOW_RESET_ADDR (IDX)'
|
471 |
|
|
Reset (i.e. zero out) the address stored in the debug register
|
472 |
|
|
number IDX.
|
473 |
|
|
|
474 |
|
|
`I386_DR_LOW_GET_STATUS'
|
475 |
|
|
Return the value of the Debug Status (DR6) register. This value is
|
476 |
|
|
used immediately after it is returned by `I386_DR_LOW_GET_STATUS',
|
477 |
|
|
so as to support per-thread status register values.
|
478 |
|
|
|
479 |
|
|
For each one of the 4 debug registers (whose indices are from 0 to 3)
|
480 |
|
|
that store addresses, a reference count is maintained by GDB, to allow
|
481 |
|
|
sharing of debug registers by several watchpoints. This allows users
|
482 |
|
|
to define several watchpoints that watch the same expression, but with
|
483 |
|
|
different conditions and/or commands, without wasting debug registers
|
484 |
|
|
which are in short supply. GDB maintains the reference counts
|
485 |
|
|
internally, targets don't have to do anything to use this feature.
|
486 |
|
|
|
487 |
|
|
The x86 debug registers can each watch a region that is 1, 2, or 4
|
488 |
|
|
bytes long. The ia32 architecture requires that each watched region be
|
489 |
|
|
appropriately aligned: 2-byte region on 2-byte boundary, 4-byte region
|
490 |
|
|
on 4-byte boundary. However, the x86 watchpoint support in GDB can
|
491 |
|
|
watch unaligned regions and regions larger than 4 bytes (up to 16
|
492 |
|
|
bytes) by allocating several debug registers to watch a single region.
|
493 |
|
|
This allocation of several registers per a watched region is also done
|
494 |
|
|
automatically without target code intervention.
|
495 |
|
|
|
496 |
|
|
The generic x86 watchpoint support provides the following API for the
|
497 |
|
|
GDB's application code:
|
498 |
|
|
|
499 |
|
|
`i386_region_ok_for_watchpoint (ADDR, LEN)'
|
500 |
|
|
The macro `TARGET_REGION_OK_FOR_HW_WATCHPOINT' is set to call this
|
501 |
|
|
function. It counts the number of debug registers required to
|
502 |
|
|
watch a given region, and returns a non-zero value if that number
|
503 |
|
|
is less than 4, the number of debug registers available to x86
|
504 |
|
|
processors.
|
505 |
|
|
|
506 |
|
|
`i386_stopped_data_address (void)'
|
507 |
|
|
The macros `STOPPED_BY_WATCHPOINT' and
|
508 |
|
|
`target_stopped_data_address' are set to call this function. The
|
509 |
|
|
argument passed to `STOPPED_BY_WATCHPOINT' is ignored. This
|
510 |
|
|
function examines the breakpoint condition bits in the DR6 Debug
|
511 |
|
|
Status register, as returned by the `I386_DR_LOW_GET_STATUS'
|
512 |
|
|
macro, and returns the address associated with the first bit that
|
513 |
|
|
is set in DR6.
|
514 |
|
|
|
515 |
|
|
`i386_insert_watchpoint (ADDR, LEN, TYPE)'
|
516 |
|
|
`i386_remove_watchpoint (ADDR, LEN, TYPE)'
|
517 |
|
|
Insert or remove a watchpoint. The macros
|
518 |
|
|
`target_insert_watchpoint' and `target_remove_watchpoint' are set
|
519 |
|
|
to call these functions. `i386_insert_watchpoint' first looks for
|
520 |
|
|
a debug register which is already set to watch the same region for
|
521 |
|
|
the same access types; if found, it just increments the reference
|
522 |
|
|
count of that debug register, thus implementing debug register
|
523 |
|
|
sharing between watchpoints. If no such register is found, the
|
524 |
|
|
function looks for a vacant debug register, sets its mirrored
|
525 |
|
|
value to ADDR, sets the mirrored value of DR7 Debug Control
|
526 |
|
|
register as appropriate for the LEN and TYPE parameters, and then
|
527 |
|
|
passes the new values of the debug register and DR7 to the
|
528 |
|
|
inferior by calling `I386_DR_LOW_SET_ADDR' and
|
529 |
|
|
`I386_DR_LOW_SET_CONTROL'. If more than one debug register is
|
530 |
|
|
required to cover the given region, the above process is repeated
|
531 |
|
|
for each debug register.
|
532 |
|
|
|
533 |
|
|
`i386_remove_watchpoint' does the opposite: it resets the address
|
534 |
|
|
in the mirrored value of the debug register and its read/write and
|
535 |
|
|
length bits in the mirrored value of DR7, then passes these new
|
536 |
|
|
values to the inferior via `I386_DR_LOW_RESET_ADDR' and
|
537 |
|
|
`I386_DR_LOW_SET_CONTROL'. If a register is shared by several
|
538 |
|
|
watchpoints, each time a `i386_remove_watchpoint' is called, it
|
539 |
|
|
decrements the reference count, and only calls
|
540 |
|
|
`I386_DR_LOW_RESET_ADDR' and `I386_DR_LOW_SET_CONTROL' when the
|
541 |
|
|
count goes to zero.
|
542 |
|
|
|
543 |
|
|
`i386_insert_hw_breakpoint (ADDR, SHADOW'
|
544 |
|
|
`i386_remove_hw_breakpoint (ADDR, SHADOW)'
|
545 |
|
|
These functions insert and remove hardware-assisted breakpoints.
|
546 |
|
|
The macros `target_insert_hw_breakpoint' and
|
547 |
|
|
`target_remove_hw_breakpoint' are set to call these functions.
|
548 |
|
|
These functions work like `i386_insert_watchpoint' and
|
549 |
|
|
`i386_remove_watchpoint', respectively, except that they set up
|
550 |
|
|
the debug registers to watch instruction execution, and each
|
551 |
|
|
hardware-assisted breakpoint always requires exactly one debug
|
552 |
|
|
register.
|
553 |
|
|
|
554 |
|
|
`i386_stopped_by_hwbp (void)'
|
555 |
|
|
This function returns non-zero if the inferior has some watchpoint
|
556 |
|
|
or hardware breakpoint that triggered. It works like
|
557 |
|
|
`i386_stopped_data_address', except that it doesn't return the
|
558 |
|
|
address whose watchpoint triggered.
|
559 |
|
|
|
560 |
|
|
`i386_cleanup_dregs (void)'
|
561 |
|
|
This function clears all the reference counts, addresses, and
|
562 |
|
|
control bits in the mirror images of the debug registers. It
|
563 |
|
|
doesn't affect the actual debug registers in the inferior process.
|
564 |
|
|
|
565 |
|
|
*Notes:*
|
566 |
|
|
1. x86 processors support setting watchpoints on I/O reads or writes.
|
567 |
|
|
However, since no target supports this (as of March 2001), and
|
568 |
|
|
since `enum target_hw_bp_type' doesn't even have an enumeration
|
569 |
|
|
for I/O watchpoints, this feature is not yet available to GDB
|
570 |
|
|
running on x86.
|
571 |
|
|
|
572 |
|
|
2. x86 processors can enable watchpoints locally, for the current task
|
573 |
|
|
only, or globally, for all the tasks. For each debug register,
|
574 |
|
|
there's a bit in the DR7 Debug Control register that determines
|
575 |
|
|
whether the associated address is watched locally or globally. The
|
576 |
|
|
current implementation of x86 watchpoint support in GDB always
|
577 |
|
|
sets watchpoints to be locally enabled, since global watchpoints
|
578 |
|
|
might interfere with the underlying OS and are probably
|
579 |
|
|
unavailable in many platforms.
|
580 |
|
|
|
581 |
|
|
|
582 |
|
|
File: gdbint.info, Node: User Interface, Next: libgdb, Prev: Algorithms, Up: Top
|
583 |
|
|
|
584 |
|
|
User Interface
|
585 |
|
|
**************
|
586 |
|
|
|
587 |
|
|
GDB has several user interfaces. Although the command-line interface
|
588 |
|
|
is the most common and most familiar, there are others.
|
589 |
|
|
|
590 |
|
|
Command Interpreter
|
591 |
|
|
===================
|
592 |
|
|
|
593 |
|
|
The command interpreter in GDB is fairly simple. It is designed to
|
594 |
|
|
allow for the set of commands to be augmented dynamically, and also has
|
595 |
|
|
a recursive subcommand capability, where the first argument to a
|
596 |
|
|
command may itself direct a lookup on a different command list.
|
597 |
|
|
|
598 |
|
|
For instance, the `set' command just starts a lookup on the
|
599 |
|
|
`setlist' command list, while `set thread' recurses to the
|
600 |
|
|
`set_thread_cmd_list'.
|
601 |
|
|
|
602 |
|
|
To add commands in general, use `add_cmd'. `add_com' adds to the
|
603 |
|
|
main command list, and should be used for those commands. The usual
|
604 |
|
|
place to add commands is in the `_initialize_XYZ' routines at the ends
|
605 |
|
|
of most source files.
|
606 |
|
|
|
607 |
|
|
To add paired `set' and `show' commands, use `add_setshow_cmd' or
|
608 |
|
|
`add_setshow_cmd_full'. The former is a slightly simpler interface
|
609 |
|
|
which is useful when you don't need to further modify the new command
|
610 |
|
|
structures, while the latter returns the new command structures for
|
611 |
|
|
manipulation.
|
612 |
|
|
|
613 |
|
|
Before removing commands from the command set it is a good idea to
|
614 |
|
|
deprecate them for some time. Use `deprecate_cmd' on commands or
|
615 |
|
|
aliases to set the deprecated flag. `deprecate_cmd' takes a `struct
|
616 |
|
|
cmd_list_element' as it's first argument. You can use the return value
|
617 |
|
|
from `add_com' or `add_cmd' to deprecate the command immediately after
|
618 |
|
|
it is created.
|
619 |
|
|
|
620 |
|
|
The first time a command is used the user will be warned and offered
|
621 |
|
|
a replacement (if one exists). Note that the replacement string passed
|
622 |
|
|
to `deprecate_cmd' should be the full name of the command, i.e. the
|
623 |
|
|
entire string the user should type at the command line.
|
624 |
|
|
|
625 |
|
|
UI-Independent Output--the `ui_out' Functions
|
626 |
|
|
=============================================
|
627 |
|
|
|
628 |
|
|
The `ui_out' functions present an abstraction level for the GDB
|
629 |
|
|
output code. They hide the specifics of different user interfaces
|
630 |
|
|
supported by GDB, and thus free the programmer from the need to write
|
631 |
|
|
several versions of the same code, one each for every UI, to produce
|
632 |
|
|
output.
|
633 |
|
|
|
634 |
|
|
Overview and Terminology
|
635 |
|
|
------------------------
|
636 |
|
|
|
637 |
|
|
In general, execution of each GDB command produces some sort of
|
638 |
|
|
output, and can even generate an input request.
|
639 |
|
|
|
640 |
|
|
Output can be generated for the following purposes:
|
641 |
|
|
|
642 |
|
|
* to display a _result_ of an operation;
|
643 |
|
|
|
644 |
|
|
* to convey _info_ or produce side-effects of a requested operation;
|
645 |
|
|
|
646 |
|
|
* to provide a _notification_ of an asynchronous event (including
|
647 |
|
|
progress indication of a prolonged asynchronous operation);
|
648 |
|
|
|
649 |
|
|
* to display _error messages_ (including warnings);
|
650 |
|
|
|
651 |
|
|
* to show _debug data_;
|
652 |
|
|
|
653 |
|
|
* to _query_ or prompt a user for input (a special case).
|
654 |
|
|
|
655 |
|
|
This section mainly concentrates on how to build result output,
|
656 |
|
|
although some of it also applies to other kinds of output.
|
657 |
|
|
|
658 |
|
|
Generation of output that displays the results of an operation
|
659 |
|
|
involves one or more of the following:
|
660 |
|
|
|
661 |
|
|
* output of the actual data
|
662 |
|
|
|
663 |
|
|
* formatting the output as appropriate for console output, to make it
|
664 |
|
|
easily readable by humans
|
665 |
|
|
|
666 |
|
|
* machine oriented formatting-a more terse formatting to allow for
|
667 |
|
|
easy parsing by programs which read GDB's output
|
668 |
|
|
|
669 |
|
|
* annotation, whose purpose is to help legacy GUIs to identify
|
670 |
|
|
interesting parts in the output
|
671 |
|
|
|
672 |
|
|
The `ui_out' routines take care of the first three aspects.
|
673 |
|
|
Annotations are provided by separate annotation routines. Note that use
|
674 |
|
|
of annotations for an interface between a GUI and GDB is deprecated.
|
675 |
|
|
|
676 |
|
|
Output can be in the form of a single item, which we call a "field";
|
677 |
|
|
a "list" consisting of identical fields; a "tuple" consisting of
|
678 |
|
|
non-identical fields; or a "table", which is a tuple consisting of a
|
679 |
|
|
header and a body. In a BNF-like form:
|
680 |
|
|
|
681 |
|
|
` ==>'
682 |
|
|
`
|
683 |
|
|
|
684 |
|
|
`
|
685 |
|
|
`{ }'
|
686 |
|
|
|
687 |
|
|
` ==>'
|
688 |
|
|
` '
|
689 |
|
|
|
690 |
|
|
` ==>'
|
691 |
|
|
`{}'
|
692 |
|
|
|
693 |
|
|
General Conventions
|
694 |
|
|
-------------------
|
695 |
|
|
|
696 |
|
|
Most `ui_out' routines are of type `void', the exceptions are
|
697 |
|
|
`ui_out_stream_new' (which returns a pointer to the newly created
|
698 |
|
|
object) and the `make_cleanup' routines.
|
699 |
|
|
|
700 |
|
|
The first parameter is always the `ui_out' vector object, a pointer
|
701 |
|
|
to a `struct ui_out'.
|
702 |
|
|
|
703 |
|
|
The FORMAT parameter is like in `printf' family of functions. When
|
704 |
|
|
it is present, there must also be a variable list of arguments
|
705 |
|
|
sufficient used to satisfy the `%' specifiers in the supplied format.
|
706 |
|
|
|
707 |
|
|
When a character string argument is not used in a `ui_out' function
|
708 |
|
|
call, a `NULL' pointer has to be supplied instead.
|
709 |
|
|
|
710 |
|
|
Table, Tuple and List Functions
|
711 |
|
|
-------------------------------
|
712 |
|
|
|
713 |
|
|
This section introduces `ui_out' routines for building lists, tuples
|
714 |
|
|
and tables. The routines to output the actual data items (fields) are
|
715 |
|
|
presented in the next section.
|
716 |
|
|
|
717 |
|
|
To recap: A "tuple" is a sequence of "fields", each field containing
|
718 |
|
|
information about an object; a "list" is a sequence of fields where
|
719 |
|
|
each field describes an identical object.
|
720 |
|
|
|
721 |
|
|
Use the "table" functions when your output consists of a list of
|
722 |
|
|
rows (tuples) and the console output should include a heading. Use this
|
723 |
|
|
even when you are listing just one object but you still want the header.
|
724 |
|
|
|
725 |
|
|
Tables can not be nested. Tuples and lists can be nested up to a
|
726 |
|
|
maximum of five levels.
|
727 |
|
|
|
728 |
|
|
The overall structure of the table output code is something like
|
729 |
|
|
this:
|
730 |
|
|
|
731 |
|
|
ui_out_table_begin
|
732 |
|
|
ui_out_table_header
|
733 |
|
|
...
|
734 |
|
|
ui_out_table_body
|
735 |
|
|
ui_out_tuple_begin
|
736 |
|
|
ui_out_field_*
|
737 |
|
|
...
|
738 |
|
|
ui_out_tuple_end
|
739 |
|
|
...
|
740 |
|
|
ui_out_table_end
|
741 |
|
|
|
742 |
|
|
Here is the description of table-, tuple- and list-related `ui_out'
|
743 |
|
|
functions:
|
744 |
|
|
|
745 |
|
|
- Function: void ui_out_table_begin (struct ui_out *UIOUT, int
|
746 |
|
|
NBROFCOLS, int NR_ROWS, const char *TBLID)
|
747 |
|
|
The function `ui_out_table_begin' marks the beginning of the output
|
748 |
|
|
of a table. It should always be called before any other `ui_out'
|
749 |
|
|
function for a given table. NBROFCOLS is the number of columns in
|
750 |
|
|
the table. NR_ROWS is the number of rows in the table. TBLID is
|
751 |
|
|
an optional string identifying the table. The string pointed to
|
752 |
|
|
by TBLID is copied by the implementation of `ui_out_table_begin',
|
753 |
|
|
so the application can free the string if it was `malloc'ed.
|
754 |
|
|
|
755 |
|
|
The companion function `ui_out_table_end', described below, marks
|
756 |
|
|
the end of the table's output.
|
757 |
|
|
|
758 |
|
|
- Function: void ui_out_table_header (struct ui_out *UIOUT, int WIDTH,
|
759 |
|
|
enum ui_align ALIGNMENT, const char *COLHDR)
|
760 |
|
|
`ui_out_table_header' provides the header information for a single
|
761 |
|
|
table column. You call this function several times, one each for
|
762 |
|
|
every column of the table, after `ui_out_table_begin', but before
|
763 |
|
|
`ui_out_table_body'.
|
764 |
|
|
|
765 |
|
|
The value of WIDTH gives the column width in characters. The
|
766 |
|
|
value of ALIGNMENT is one of `left', `center', and `right', and it
|
767 |
|
|
specifies how to align the header: left-justify, center, or
|
768 |
|
|
right-justify it. COLHDR points to a string that specifies the
|
769 |
|
|
column header; the implementation copies that string, so column
|
770 |
|
|
header strings in `malloc'ed storage can be freed after the call.
|
771 |
|
|
|
772 |
|
|
- Function: void ui_out_table_body (struct ui_out *UIOUT)
|
773 |
|
|
This function delimits the table header from the table body.
|
774 |
|
|
|
775 |
|
|
- Function: void ui_out_table_end (struct ui_out *UIOUT)
|
776 |
|
|
This function signals the end of a table's output. It should be
|
777 |
|
|
called after the table body has been produced by the list and
|
778 |
|
|
field output functions.
|
779 |
|
|
|
780 |
|
|
There should be exactly one call to `ui_out_table_end' for each
|
781 |
|
|
call to `ui_out_table_begin', otherwise the `ui_out' functions
|
782 |
|
|
will signal an internal error.
|
783 |
|
|
|
784 |
|
|
The output of the tuples that represent the table rows must follow
|
785 |
|
|
the call to `ui_out_table_body' and precede the call to
|
786 |
|
|
`ui_out_table_end'. You build a tuple by calling `ui_out_tuple_begin'
|
787 |
|
|
and `ui_out_tuple_end', with suitable calls to functions which actually
|
788 |
|
|
output fields between them.
|
789 |
|
|
|
790 |
|
|
- Function: void ui_out_tuple_begin (struct ui_out *UIOUT, const char
|
791 |
|
|
*ID)
|
792 |
|
|
This function marks the beginning of a tuple output. ID points to
|
793 |
|
|
an optional string that identifies the tuple; it is copied by the
|
794 |
|
|
implementation, and so strings in `malloc'ed storage can be freed
|
795 |
|
|
after the call.
|
796 |
|
|
|
797 |
|
|
- Function: void ui_out_tuple_end (struct ui_out *UIOUT)
|
798 |
|
|
This function signals an end of a tuple output. There should be
|
799 |
|
|
exactly one call to `ui_out_tuple_end' for each call to
|
800 |
|
|
`ui_out_tuple_begin', otherwise an internal GDB error will be
|
801 |
|
|
signaled.
|
802 |
|
|
|
803 |
|
|
- Function: struct cleanup *make_cleanup_ui_out_tuple_begin_end
|
804 |
|
|
(struct ui_out *UIOUT, const char *ID)
|
805 |
|
|
This function first opens the tuple and then establishes a cleanup
|
806 |
|
|
(*note Cleanups: Coding.) to close the tuple. It provides a
|
807 |
|
|
convenient and correct implementation of the non-portable(1) code
|
808 |
|
|
sequence:
|
809 |
|
|
struct cleanup *old_cleanup;
|
810 |
|
|
ui_out_tuple_begin (uiout, "...");
|
811 |
|
|
old_cleanup = make_cleanup ((void(*)(void *)) ui_out_tuple_end,
|
812 |
|
|
uiout);
|
813 |
|
|
|
814 |
|
|
- Function: void ui_out_list_begin (struct ui_out *UIOUT, const char
|
815 |
|
|
*ID)
|
816 |
|
|
This function marks the beginning of a list output. ID points to
|
817 |
|
|
an optional string that identifies the list; it is copied by the
|
818 |
|
|
implementation, and so strings in `malloc'ed storage can be freed
|
819 |
|
|
after the call.
|
820 |
|
|
|
821 |
|
|
- Function: void ui_out_list_end (struct ui_out *UIOUT)
|
822 |
|
|
This function signals an end of a list output. There should be
|
823 |
|
|
exactly one call to `ui_out_list_end' for each call to
|
824 |
|
|
`ui_out_list_begin', otherwise an internal GDB error will be
|
825 |
|
|
signaled.
|
826 |
|
|
|
827 |
|
|
- Function: struct cleanup *make_cleanup_ui_out_list_begin_end (struct
|
828 |
|
|
ui_out *UIOUT, const char *ID)
|
829 |
|
|
Similar to `make_cleanup_ui_out_tuple_begin_end', this function
|
830 |
|
|
opens a list and then establishes cleanup (*note Cleanups: Coding.)
|
831 |
|
|
that will close the list.list.
|
832 |
|
|
|
833 |
|
|
Item Output Functions
|
834 |
|
|
---------------------
|
835 |
|
|
|
836 |
|
|
The functions described below produce output for the actual data
|
837 |
|
|
items, or fields, which contain information about the object.
|
838 |
|
|
|
839 |
|
|
Choose the appropriate function accordingly to your particular needs.
|
840 |
|
|
|
841 |
|
|
- Function: void ui_out_field_fmt (struct ui_out *UIOUT, char
|
842 |
|
|
*FLDNAME, char *FORMAT, ...)
|
843 |
|
|
This is the most general output function. It produces the
|
844 |
|
|
representation of the data in the variable-length argument list
|
845 |
|
|
according to formatting specifications in FORMAT, a `printf'-like
|
846 |
|
|
format string. The optional argument FLDNAME supplies the name of
|
847 |
|
|
the field. The data items themselves are supplied as additional
|
848 |
|
|
arguments after FORMAT.
|
849 |
|
|
|
850 |
|
|
This generic function should be used only when it is not possible
|
851 |
|
|
to use one of the specialized versions (see below).
|
852 |
|
|
|
853 |
|
|
- Function: void ui_out_field_int (struct ui_out *UIOUT, const char
|
854 |
|
|
*FLDNAME, int VALUE)
|
855 |
|
|
This function outputs a value of an `int' variable. It uses the
|
856 |
|
|
`"%d"' output conversion specification. FLDNAME specifies the
|
857 |
|
|
name of the field.
|
858 |
|
|
|
859 |
|
|
- Function: void ui_out_field_core_addr (struct ui_out *UIOUT, const
|
860 |
|
|
char *FLDNAME, CORE_ADDR ADDRESS)
|
861 |
|
|
This function outputs an address.
|
862 |
|
|
|
863 |
|
|
- Function: void ui_out_field_string (struct ui_out *UIOUT, const char
|
864 |
|
|
*FLDNAME, const char *STRING)
|
865 |
|
|
This function outputs a string using the `"%s"' conversion
|
866 |
|
|
specification.
|
867 |
|
|
|
868 |
|
|
Sometimes, there's a need to compose your output piece by piece using
|
869 |
|
|
functions that operate on a stream, such as `value_print' or
|
870 |
|
|
`fprintf_symbol_filtered'. These functions accept an argument of the
|
871 |
|
|
type `struct ui_file *', a pointer to a `ui_file' object used to store
|
872 |
|
|
the data stream used for the output. When you use one of these
|
873 |
|
|
functions, you need a way to pass their results stored in a `ui_file'
|
874 |
|
|
object to the `ui_out' functions. To this end, you first create a
|
875 |
|
|
`ui_stream' object by calling `ui_out_stream_new', pass the `stream'
|
876 |
|
|
member of that `ui_stream' object to `value_print' and similar
|
877 |
|
|
functions, and finally call `ui_out_field_stream' to output the field
|
878 |
|
|
you constructed. When the `ui_stream' object is no longer needed, you
|
879 |
|
|
should destroy it and free its memory by calling `ui_out_stream_delete'.
|
880 |
|
|
|
881 |
|
|
- Function: struct ui_stream *ui_out_stream_new (struct ui_out *UIOUT)
|
882 |
|
|
This function creates a new `ui_stream' object which uses the same
|
883 |
|
|
output methods as the `ui_out' object whose pointer is passed in
|
884 |
|
|
UIOUT. It returns a pointer to the newly created `ui_stream'
|
885 |
|
|
object.
|
886 |
|
|
|
887 |
|
|
- Function: void ui_out_stream_delete (struct ui_stream *STREAMBUF)
|
888 |
|
|
This functions destroys a `ui_stream' object specified by
|
889 |
|
|
STREAMBUF.
|
890 |
|
|
|
891 |
|
|
- Function: void ui_out_field_stream (struct ui_out *UIOUT, const char
|
892 |
|
|
*FIELDNAME, struct ui_stream *STREAMBUF)
|
893 |
|
|
This function consumes all the data accumulated in
|
894 |
|
|
`streambuf->stream' and outputs it like `ui_out_field_string'
|
895 |
|
|
does. After a call to `ui_out_field_stream', the accumulated data
|
896 |
|
|
no longer exists, but the stream is still valid and may be used
|
897 |
|
|
for producing more fields.
|
898 |
|
|
|
899 |
|
|
*Important:* If there is any chance that your code could bail out
|
900 |
|
|
before completing output generation and reaching the point where
|
901 |
|
|
`ui_out_stream_delete' is called, it is necessary to set up a cleanup,
|
902 |
|
|
to avoid leaking memory and other resources. Here's a skeleton code to
|
903 |
|
|
do that:
|
904 |
|
|
|
905 |
|
|
struct ui_stream *mybuf = ui_out_stream_new (uiout);
|
906 |
|
|
struct cleanup *old = make_cleanup (ui_out_stream_delete, mybuf);
|
907 |
|
|
...
|
908 |
|
|
do_cleanups (old);
|
909 |
|
|
|
910 |
|
|
If the function already has the old cleanup chain set (for other
|
911 |
|
|
kinds of cleanups), you just have to add your cleanup to it:
|
912 |
|
|
|
913 |
|
|
mybuf = ui_out_stream_new (uiout);
|
914 |
|
|
make_cleanup (ui_out_stream_delete, mybuf);
|
915 |
|
|
|
916 |
|
|
Note that with cleanups in place, you should not call
|
917 |
|
|
`ui_out_stream_delete' directly, or you would attempt to free the same
|
918 |
|
|
buffer twice.
|
919 |
|
|
|
920 |
|
|
Utility Output Functions
|
921 |
|
|
------------------------
|
922 |
|
|
|
923 |
|
|
- Function: void ui_out_field_skip (struct ui_out *UIOUT, const char
|
924 |
|
|
*FLDNAME)
|
925 |
|
|
This function skips a field in a table. Use it if you have to
|
926 |
|
|
leave an empty field without disrupting the table alignment. The
|
927 |
|
|
argument FLDNAME specifies a name for the (missing) filed.
|
928 |
|
|
|
929 |
|
|
- Function: void ui_out_text (struct ui_out *UIOUT, const char *STRING)
|
930 |
|
|
This function outputs the text in STRING in a way that makes it
|
931 |
|
|
easy to be read by humans. For example, the console
|
932 |
|
|
implementation of this method filters the text through a built-in
|
933 |
|
|
pager, to prevent it from scrolling off the visible portion of the
|
934 |
|
|
screen.
|
935 |
|
|
|
936 |
|
|
Use this function for printing relatively long chunks of text
|
937 |
|
|
around the actual field data: the text it produces is not aligned
|
938 |
|
|
according to the table's format. Use `ui_out_field_string' to
|
939 |
|
|
output a string field, and use `ui_out_message', described below,
|
940 |
|
|
to output short messages.
|
941 |
|
|
|
942 |
|
|
- Function: void ui_out_spaces (struct ui_out *UIOUT, int NSPACES)
|
943 |
|
|
This function outputs NSPACES spaces. It is handy to align the
|
944 |
|
|
text produced by `ui_out_text' with the rest of the table or list.
|
945 |
|
|
|
946 |
|
|
- Function: void ui_out_message (struct ui_out *UIOUT, int VERBOSITY,
|
947 |
|
|
const char *FORMAT, ...)
|
948 |
|
|
This function produces a formatted message, provided that the
|
949 |
|
|
current verbosity level is at least as large as given by
|
950 |
|
|
VERBOSITY. The current verbosity level is specified by the user
|
951 |
|
|
with the `set verbositylevel' command.(2)
|
952 |
|
|
|
953 |
|
|
- Function: void ui_out_wrap_hint (struct ui_out *UIOUT, char *INDENT)
|
954 |
|
|
This function gives the console output filter (a paging filter) a
|
955 |
|
|
hint of where to break lines which are too long. Ignored for all
|
956 |
|
|
other output consumers. INDENT, if non-`NULL', is the string to
|
957 |
|
|
be printed to indent the wrapped text on the next line; it must
|
958 |
|
|
remain accessible until the next call to `ui_out_wrap_hint', or
|
959 |
|
|
until an explicit newline is produced by one of the other
|
960 |
|
|
functions. If INDENT is `NULL', the wrapped text will not be
|
961 |
|
|
indented.
|
962 |
|
|
|
963 |
|
|
- Function: void ui_out_flush (struct ui_out *UIOUT)
|
964 |
|
|
This function flushes whatever output has been accumulated so far,
|
965 |
|
|
if the UI buffers output.
|
966 |
|
|
|
967 |
|
|
Examples of Use of `ui_out' functions
|
968 |
|
|
-------------------------------------
|
969 |
|
|
|
970 |
|
|
This section gives some practical examples of using the `ui_out'
|
971 |
|
|
functions to generalize the old console-oriented code in GDB. The
|
972 |
|
|
examples all come from functions defined on the `breakpoints.c' file.
|
973 |
|
|
|
974 |
|
|
This example, from the `breakpoint_1' function, shows how to produce
|
975 |
|
|
a table.
|
976 |
|
|
|
977 |
|
|
The original code was:
|
978 |
|
|
|
979 |
|
|
if (!found_a_breakpoint++)
|
980 |
|
|
{
|
981 |
|
|
annotate_breakpoints_headers ();
|
982 |
|
|
|
983 |
|
|
annotate_field (0);
|
984 |
|
|
printf_filtered ("Num ");
|
985 |
|
|
annotate_field (1);
|
986 |
|
|
printf_filtered ("Type ");
|
987 |
|
|
annotate_field (2);
|
988 |
|
|
printf_filtered ("Disp ");
|
989 |
|
|
annotate_field (3);
|
990 |
|
|
printf_filtered ("Enb ");
|
991 |
|
|
if (addressprint)
|
992 |
|
|
{
|
993 |
|
|
annotate_field (4);
|
994 |
|
|
printf_filtered ("Address ");
|
995 |
|
|
}
|
996 |
|
|
annotate_field (5);
|
997 |
|
|
printf_filtered ("What\n");
|
998 |
|
|
|
999 |
|
|
annotate_breakpoints_table ();
|
1000 |
|
|
}
|
1001 |
|
|
|
1002 |
|
|
Here's the new version:
|
1003 |
|
|
|
1004 |
|
|
nr_printable_breakpoints = ...;
|
1005 |
|
|
|
1006 |
|
|
if (addressprint)
|
1007 |
|
|
ui_out_table_begin (ui, 6, nr_printable_breakpoints, "BreakpointTable");
|
1008 |
|
|
else
|
1009 |
|
|
ui_out_table_begin (ui, 5, nr_printable_breakpoints, "BreakpointTable");
|
1010 |
|
|
|
1011 |
|
|
if (nr_printable_breakpoints > 0)
|
1012 |
|
|
annotate_breakpoints_headers ();
|
1013 |
|
|
if (nr_printable_breakpoints > 0)
|
1014 |
|
|
annotate_field (0);
|
1015 |
|
|
ui_out_table_header (uiout, 3, ui_left, "number", "Num"); /* 1 */
|
1016 |
|
|
if (nr_printable_breakpoints > 0)
|
1017 |
|
|
annotate_field (1);
|
1018 |
|
|
ui_out_table_header (uiout, 14, ui_left, "type", "Type"); /* 2 */
|
1019 |
|
|
if (nr_printable_breakpoints > 0)
|
1020 |
|
|
annotate_field (2);
|
1021 |
|
|
ui_out_table_header (uiout, 4, ui_left, "disp", "Disp"); /* 3 */
|
1022 |
|
|
if (nr_printable_breakpoints > 0)
|
1023 |
|
|
annotate_field (3);
|
1024 |
|
|
ui_out_table_header (uiout, 3, ui_left, "enabled", "Enb"); /* 4 */
|
1025 |
|
|
if (addressprint)
|
1026 |
|
|
{
|
1027 |
|
|
if (nr_printable_breakpoints > 0)
|
1028 |
|
|
annotate_field (4);
|
1029 |
|
|
if (TARGET_ADDR_BIT <= 32)
|
1030 |
|
|
ui_out_table_header (uiout, 10, ui_left, "addr", "Address");/* 5 */
|
1031 |
|
|
else
|
1032 |
|
|
ui_out_table_header (uiout, 18, ui_left, "addr", "Address");/* 5 */
|
1033 |
|
|
}
|
1034 |
|
|
if (nr_printable_breakpoints > 0)
|
1035 |
|
|
annotate_field (5);
|
1036 |
|
|
ui_out_table_header (uiout, 40, ui_noalign, "what", "What"); /* 6 */
|
1037 |
|
|
ui_out_table_body (uiout);
|
1038 |
|
|
if (nr_printable_breakpoints > 0)
|
1039 |
|
|
annotate_breakpoints_table ();
|
1040 |
|
|
|
1041 |
|
|
This example, from the `print_one_breakpoint' function, shows how to
|
1042 |
|
|
produce the actual data for the table whose structure was defined in
|
1043 |
|
|
the above example. The original code was:
|
1044 |
|
|
|
1045 |
|
|
annotate_record ();
|
1046 |
|
|
annotate_field (0);
|
1047 |
|
|
printf_filtered ("%-3d ", b->number);
|
1048 |
|
|
annotate_field (1);
|
1049 |
|
|
if ((int)b->type > (sizeof(bptypes)/sizeof(bptypes[0]))
|
1050 |
|
|
|| ((int) b->type != bptypes[(int) b->type].type))
|
1051 |
|
|
internal_error ("bptypes table does not describe type #%d.",
|
1052 |
|
|
(int)b->type);
|
1053 |
|
|
printf_filtered ("%-14s ", bptypes[(int)b->type].description);
|
1054 |
|
|
annotate_field (2);
|
1055 |
|
|
printf_filtered ("%-4s ", bpdisps[(int)b->disposition]);
|
1056 |
|
|
annotate_field (3);
|
1057 |
|
|
printf_filtered ("%-3c ", bpenables[(int)b->enable]);
|
1058 |
|
|
...
|
1059 |
|
|
|
1060 |
|
|
This is the new version:
|
1061 |
|
|
|
1062 |
|
|
annotate_record ();
|
1063 |
|
|
ui_out_tuple_begin (uiout, "bkpt");
|
1064 |
|
|
annotate_field (0);
|
1065 |
|
|
ui_out_field_int (uiout, "number", b->number);
|
1066 |
|
|
annotate_field (1);
|
1067 |
|
|
if (((int) b->type > (sizeof (bptypes) / sizeof (bptypes[0])))
|
1068 |
|
|
|| ((int) b->type != bptypes[(int) b->type].type))
|
1069 |
|
|
internal_error ("bptypes table does not describe type #%d.",
|
1070 |
|
|
(int) b->type);
|
1071 |
|
|
ui_out_field_string (uiout, "type", bptypes[(int)b->type].description);
|
1072 |
|
|
annotate_field (2);
|
1073 |
|
|
ui_out_field_string (uiout, "disp", bpdisps[(int)b->disposition]);
|
1074 |
|
|
annotate_field (3);
|
1075 |
|
|
ui_out_field_fmt (uiout, "enabled", "%c", bpenables[(int)b->enable]);
|
1076 |
|
|
...
|
1077 |
|
|
|
1078 |
|
|
This example, also from `print_one_breakpoint', shows how to produce
|
1079 |
|
|
a complicated output field using the `print_expression' functions which
|
1080 |
|
|
requires a stream to be passed. It also shows how to automate stream
|
1081 |
|
|
destruction with cleanups. The original code was:
|
1082 |
|
|
|
1083 |
|
|
annotate_field (5);
|
1084 |
|
|
print_expression (b->exp, gdb_stdout);
|
1085 |
|
|
|
1086 |
|
|
The new version is:
|
1087 |
|
|
|
1088 |
|
|
struct ui_stream *stb = ui_out_stream_new (uiout);
|
1089 |
|
|
struct cleanup *old_chain = make_cleanup_ui_out_stream_delete (stb);
|
1090 |
|
|
...
|
1091 |
|
|
annotate_field (5);
|
1092 |
|
|
print_expression (b->exp, stb->stream);
|
1093 |
|
|
ui_out_field_stream (uiout, "what", local_stream);
|
1094 |
|
|
|
1095 |
|
|
This example, also from `print_one_breakpoint', shows how to use
|
1096 |
|
|
`ui_out_text' and `ui_out_field_string'. The original code was:
|
1097 |
|
|
|
1098 |
|
|
annotate_field (5);
|
1099 |
|
|
if (b->dll_pathname == NULL)
|
1100 |
|
|
printf_filtered (" ");
|
1101 |
|
|
else
|
1102 |
|
|
printf_filtered ("library \"%s\" ", b->dll_pathname);
|
1103 |
|
|
|
1104 |
|
|
It became:
|
1105 |
|
|
|
1106 |
|
|
annotate_field (5);
|
1107 |
|
|
if (b->dll_pathname == NULL)
|
1108 |
|
|
{
|
1109 |
|
|
ui_out_field_string (uiout, "what", "");
|
1110 |
|
|
ui_out_spaces (uiout, 1);
|
1111 |
|
|
}
|
1112 |
|
|
else
|
1113 |
|
|
{
|
1114 |
|
|
ui_out_text (uiout, "library \"");
|
1115 |
|
|
ui_out_field_string (uiout, "what", b->dll_pathname);
|
1116 |
|
|
ui_out_text (uiout, "\" ");
|
1117 |
|
|
}
|
1118 |
|
|
|
1119 |
|
|
The following example from `print_one_breakpoint' shows how to use
|
1120 |
|
|
`ui_out_field_int' and `ui_out_spaces'. The original code was:
|
1121 |
|
|
|
1122 |
|
|
annotate_field (5);
|
1123 |
|
|
if (b->forked_inferior_pid != 0)
|
1124 |
|
|
printf_filtered ("process %d ", b->forked_inferior_pid);
|
1125 |
|
|
|
1126 |
|
|
It became:
|
1127 |
|
|
|
1128 |
|
|
annotate_field (5);
|
1129 |
|
|
if (b->forked_inferior_pid != 0)
|
1130 |
|
|
{
|
1131 |
|
|
ui_out_text (uiout, "process ");
|
1132 |
|
|
ui_out_field_int (uiout, "what", b->forked_inferior_pid);
|
1133 |
|
|
ui_out_spaces (uiout, 1);
|
1134 |
|
|
}
|
1135 |
|
|
|
1136 |
|
|
Here's an example of using `ui_out_field_string'. The original code
|
1137 |
|
|
was:
|
1138 |
|
|
|
1139 |
|
|
annotate_field (5);
|
1140 |
|
|
if (b->exec_pathname != NULL)
|
1141 |
|
|
printf_filtered ("program \"%s\" ", b->exec_pathname);
|
1142 |
|
|
|
1143 |
|
|
It became:
|
1144 |
|
|
|
1145 |
|
|
annotate_field (5);
|
1146 |
|
|
if (b->exec_pathname != NULL)
|
1147 |
|
|
{
|
1148 |
|
|
ui_out_text (uiout, "program \"");
|
1149 |
|
|
ui_out_field_string (uiout, "what", b->exec_pathname);
|
1150 |
|
|
ui_out_text (uiout, "\" ");
|
1151 |
|
|
}
|
1152 |
|
|
|
1153 |
|
|
Finally, here's an example of printing an address. The original
|
1154 |
|
|
code:
|
1155 |
|
|
|
1156 |
|
|
annotate_field (4);
|
1157 |
|
|
printf_filtered ("%s ",
|
1158 |
|
|
local_hex_string_custom ((unsigned long) b->address, "08l"));
|
1159 |
|
|
|
1160 |
|
|
It became:
|
1161 |
|
|
|
1162 |
|
|
annotate_field (4);
|
1163 |
|
|
ui_out_field_core_addr (uiout, "Address", b->address);
|
1164 |
|
|
|
1165 |
|
|
Console Printing
|
1166 |
|
|
================
|
1167 |
|
|
|
1168 |
|
|
TUI
|
1169 |
|
|
===
|
1170 |
|
|
|
1171 |
|
|
---------- Footnotes ----------
|
1172 |
|
|
|
1173 |
|
|
(1) The function cast is not portable ISO C.
|
1174 |
|
|
|
1175 |
|
|
(2) As of this writing (April 2001), setting verbosity level is not
|
1176 |
|
|
yet implemented, and is always returned as zero. So calling
|
1177 |
|
|
`ui_out_message' with a VERBOSITY argument more than zero will cause
|
1178 |
|
|
the message to never be printed.
|
1179 |
|
|
|
© copyright 1999-2024
OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.
|