1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
|
Notes for the branch "gdb-csl-available-20060303-branch"
--------------------------------------------------------
This branch implements a new mechanism which allows GDB to ask a target
"what features do you have?" GDB can then interpret the response and
dynamically present those features to the user. Some features require
corresponding support in GDB, and must be specially recognized by the target
architecture. Others do not require additional GDB support, e.g. additional
registers (the only type of feature implemented so far).
The branch does not have a ChangeLog relative to mainline; one will be written
later. So far, only the ARM target has any support for available features.
The most interesting portion of this document is the TODO list; the rest may
get somewhat out of date.
Control flow in GDB
-------------------
After connecting to the target, we check the new architecture-provided setting
gdbarch_available_features_support. If it is set, we query the target
for its available features, interpret the response, and switch to a new
gdbarch, derived from the current one, with these features recorded.
In order for the derivation process to work, the architecture's gdbarch_init
must correctly support filling in defaults based on the last used architecture.
If it does not, for example, cache something read from the ELF binary in
gdbarch_tdep, the architecture is likely to get out of sync with the
debuggee.
During debugging, GDB can query information from the current set of
features. This is currently done in architecture-specific hooks, but may be
done in common code in the future.
Writing a feature description
-----------------------------
Feature descriptions are written in XML. The current DTD is in
gdb/features/gdb-target.dtd. There are some limits beyond those
expressed in the DTD - many of these limits are not yet documented
and not yet relevant until additional GDB support has been implemented.
See the TODO.
Here's a simple sample description:
<?xml version="1.0"?>
<!DOCTYPE target SYSTEM "gdb-target.dtd">
<target>
<feature name="bar">
<reg name="s0" bitsize="32"/>
<reg name="s1" bitsize="32" type="float"/>
</feature>
<feature-set>
<feature-ref name="bar" base-regnum="1"/>
</feature-set>
</target>
This describes a simple target feature set which only contains two registers,
named s0 (32-bit, integer) and s1 (32-bit, floating point).
You can spread a description over multiple files by using the standardized
XInclude mechanism - but only whole-file XInclude is supported. The
xpointer attribute should not be used, and the href attribute should be,
using a bare basename. GDB will query the target for the file, if it has
not already seen it.
You can validate the description using any XML validator which supports XInclude.
For instance, with "xmllint" (shipped as part of the GNOME libxml2 package):
xmllint --xinclude --postvalid my-target.xml
Post validation is usually appropriate when using XInclude; the DTD describes
the document after XInclude processing.
GDB fetches CHECKSUMS initially. Files with a listed checksum may be
fetched from a cache instead of from the target (currently only RAM caching
is implemented). Next, GDB fetches "target.xml", and then any files
included using XInclude. Files not listed in CHECKSUMS will not be fetched
from the cache - they may be e.g. generated on the fly. The target
description is fetched on connect, and again after application restart in
case it has changed (TODO: is this wasteful, should it be fetched only
once? This only matters for target extended-remote, so it isn't a big
deal right now.)
By default, feature names must be unique within the document (XML "ID"
constraint), but not globally unique. However, GDB must recognize some
features explicitly to enable additional support for them. It uses the
feature name to detect their presence. These features should have
unambiguous, globally unique names. If the feature is described in the GDB
manual, use the name listed there. If not, and you are adding code to a
local version of GDB to recognize the feature by name, please use a name
which includes your organization. For instance, "org.gnu.gdb.arm.core", or
"com.codesourcery.foovendor.coproc". This method prevents conflicts with
other names chosen by other groups.
The target description should specify every register provided by the
target, including the GDB standard ones.
TODO items and unsettled (or unasked) questions
-----------------------------------------------
When finished this documentation needs to move into the user and internals
manual.
The "ro" and "save-restore" tags may not express enough information about
how to treat system registers. Richard Earnshaw suggested a more detailed
categorization; I need to consider it; I think it's a good idea at first
glance.
Reading and writing registers using the 'p' and 'P' packets is very
inefficient; a target mechanism and remote protocol packets for multiple
register batching would probably help a lot. Note, the branch now does a
simple subset of this assuming a reasonable 'g' packet.
For ARM VFP, there are two views of some registers: s0 / s1 are single precision
registers overlayed in storage with d0, a double precision register. Many
other targets do the same thing. Should we express this to GDB, or just
allow it to read them both from the target (somewhat wasteful)? GDB already
assumes that modifying one register may modify another unpredictably, so
writing is OK - the only problem is a waste of bandwidth.
The DTD allows for description fields, including multi-lingual ones, but
there is no GDB support for descriptions. It would be good to present
them to the user.
Should we convey the information read from the target (after e.g. XInclude
processing) to MI front ends, or are the changes to the register cache
sufficient? For instance, Eclipse would probably be happy to display most
of this data (especially descriptions). I think there should be one MI
command to fetch the DTD used, and another to fetch the description used.
XInclude processing has been moved into a separate phase to facilitate this.
Because other external entities are not supported, these two are guaranteed
to convey the entire description.
The current DTD and GDB support does not allow for nested features. This
is probably useful. I think this will be a must-have in the long term.
GDB needs additional error checking for its assumptions of unique names.
For instance, there may be multiple registers with the same name in
GDB's feature database, but they had better not be instantiated in
the same feature set.
Should known features be compiled in to GDB, or loaded from the filesystem?
The most essential features should probably be compiled in, so that the GDB
binary is useful standalone. The DTD is already compiled in, but there's no
support for a target to supply default features by XML instead of hand
coding.
GDB should support reading features and feature sets from disk instead of
from the target.
GDB should support caching features read from the target in a user-specified
directory.
Should GDB warn about unrecognized features which require additional GDB
support, or silently ignore them? Currently there is no way to detect
this. It's not a big deal.
Since the name field of features may be hierarchical, and the description is
free-form (more like "help text"), there should probably be a "short
description" field - a user label without the uniqueness constraint.
Another suggested type of feature is a memory map - which areas of memory
the debugger may read from / write to.
Targets could use XML to supply their default feature set. It's nice in that
it moves a bit of code from the tdep files out into a description file; but
less nice in that it might lose flexibility that we need; the target might
have to run-time generate the XML. Currently there are no plans to require
this, but it may turn out to be a simplifying assumption later.
Register group handling right now is somewhat simplistic; only
group="general", group="float", group="vector", and no explicit group
setting (use type to categorize) are supported. We could extend this, or
we could limit it to those and provide an alternate hierarchy based on
the containing features.
Eventually supporting multiple instances of a feature is desirable. This
requires some instance-name on the feature reference, and using that to
prefix the registers for that feature. Maybe treat the registers as a large
struct. This would be sort of useful anyway, to avoid clobbering
the convenience variable namespace. Maybe only "core" registers should
be in the default namespace? Maybe key that off the description, empty
or missing instance-name -> default namespace?
In the mean time, GDB should check for duplicated register names, and
warn that it can not support them.
Should hardware MMIO registers be treated as registers, or as memory, or
using new read/write packets that can guarantee appropriate I/O width?
If as registers, we need to be careful with ones where reading them
triggers an action (e.g. resetting some state).
A nice-to-have item would be a basic architecture identifier:
(gdb) target remote board:2345
warning: This GDB does not support the "arm" architecture.
Should the current extended-remote be changed from a client-requested
property ("!" packet) to a target-announced property? Some stubs
should always be used in extended mode, some don't support it. Some
get by with either, but usually, not very well.
|
