1 |
1026 |
ivang |
@c
|
2 |
|
|
@c RTEMS Remote Debugger Server Specifications
|
3 |
|
|
@c
|
4 |
|
|
@c Written by: Eric Valette
|
5 |
|
|
@c Emmanuel Raguet
|
6 |
|
|
@c
|
7 |
|
|
@c
|
8 |
|
|
@c gdbinternals.t,v 1.7 2002/01/17 21:47:46 joel Exp
|
9 |
|
|
@c
|
10 |
|
|
|
11 |
|
|
@chapter A Rapid Tour of GDB Internals
|
12 |
|
|
|
13 |
|
|
To help the reader to understand what needs to be implemented, we
|
14 |
|
|
will present briefly how GDB works regardless if the target is local or remote.
|
15 |
|
|
A debugger is a tool which enables control of the execution of software on a
|
16 |
|
|
target system. In most of cases, the debugger connects to a target system, attaches
|
17 |
|
|
a process, inserts breakpoints and resumes execution. Then the normal execution
|
18 |
|
|
is completely events driven (process execution stopped due to a breakpoint,
|
19 |
|
|
process fault, single-step,...) coming from the debuggee. It can also directly
|
20 |
|
|
access some parts of the target processor context (registers, data memory, code
|
21 |
|
|
memory,...) and change their content. Native GDB debugger can just be seen as
|
22 |
|
|
special cases where the host and the target are on the same machine and GDB
|
23 |
|
|
can directly access the target system debug API.
|
24 |
|
|
|
25 |
|
|
|
26 |
|
|
In our case, the host and the target are not on the same machine and
|
27 |
|
|
an Ethernet link is used to communicate between the different machines. Because
|
28 |
|
|
GDB needs to be able to support various targets (including Unix core file, ...),
|
29 |
|
|
each action that needs to be performed on the debuggee is materialized by a
|
30 |
|
|
field of the following @emph{targets_op}s structure :
|
31 |
|
|
|
32 |
|
|
@example
|
33 |
|
|
struct target_ops
|
34 |
|
|
@{
|
35 |
|
|
char *to_shortname; /* Name this target type */
|
36 |
|
|
char *to_longname; /* Name for printing */
|
37 |
|
|
char *to_doc; /* Documentation. Does not include trailing
|
38 |
|
|
newline, and starts with a one-line
|
39 |
|
|
description (probably similar to
|
40 |
|
|
to_longname). */
|
41 |
|
|
void (*to_open) PARAMS ((char *, int));
|
42 |
|
|
void (*to_close) PARAMS ((int));
|
43 |
|
|
void (*to_attach) PARAMS ((char *, int));
|
44 |
|
|
void (*to_detach) PARAMS ((char *, int));
|
45 |
|
|
void (*to_resume) PARAMS ((int, int, enum target_signal));
|
46 |
|
|
int (*to_wait) PARAMS ((int, struct target_waitstatus *));
|
47 |
|
|
void (*to_fetch_registers) PARAMS ((int));
|
48 |
|
|
void (*to_store_registers) PARAMS ((int));
|
49 |
|
|
void (*to_prepare_to_store) PARAMS ((void));
|
50 |
|
|
|
51 |
|
|
/* Transfer LEN bytes of memory between GDB address MYADDR and
|
52 |
|
|
target address MEMADDR. If WRITE, transfer them to the target,
|
53 |
|
|
else transfer them from the target. TARGET is the target from
|
54 |
|
|
which we get this function.
|
55 |
|
|
|
56 |
|
|
Return value, N, is one of the following:
|
57 |
|
|
|
58 |
|
|
|
59 |
|
|
it is the error which prevented us from doing it (FIXME:
|
60 |
|
|
What about bfd_error?).
|
61 |
|
|
|
62 |
|
|
positive (call it N) means that we have transferred N bytes
|
63 |
|
|
starting at MEMADDR. We might be able to handle more bytes
|
64 |
|
|
beyond this length, but no promises.
|
65 |
|
|
|
66 |
|
|
negative (call its absolute value N) means that we cannot
|
67 |
|
|
transfer right at MEMADDR, but we could transfer at least
|
68 |
|
|
something at MEMADDR + N. */
|
69 |
|
|
|
70 |
|
|
int (*to_xfer_memory)
|
71 |
|
|
PARAMS ((CORE_ADDR memaddr, char *myaddr,
|
72 |
|
|
int len, int write,
|
73 |
|
|
struct target_ops * target));
|
74 |
|
|
|
75 |
|
|
void (*to_files_info) PARAMS ((struct target_ops *));
|
76 |
|
|
int (*to_insert_breakpoint) PARAMS ((CORE_ADDR, char *));
|
77 |
|
|
int (*to_remove_breakpoint) PARAMS ((CORE_ADDR, char *));
|
78 |
|
|
void (*to_terminal_init) PARAMS ((void));
|
79 |
|
|
void (*to_terminal_inferior) PARAMS ((void));
|
80 |
|
|
void (*to_terminal_ours_for_output) PARAMS ((void));
|
81 |
|
|
void (*to_terminal_ours) PARAMS ((void));
|
82 |
|
|
void (*to_terminal_info) PARAMS ((char *, int));
|
83 |
|
|
void (*to_kill) PARAMS ((void));
|
84 |
|
|
void (*to_load) PARAMS ((char *, int));
|
85 |
|
|
int (*to_lookup_symbol) PARAMS ((char *, CORE_ADDR *));
|
86 |
|
|
void (*to_create_inferior) PARAMS ((char *, char *, char **));
|
87 |
|
|
void (*to_mourn_inferior) PARAMS ((void));
|
88 |
|
|
int (*to_can_run) PARAMS ((void));
|
89 |
|
|
void (*to_notice_signals) PARAMS ((int pid));
|
90 |
|
|
int (*to_thread_alive) PARAMS ((int pid));
|
91 |
|
|
void (*to_stop) PARAMS ((void));
|
92 |
|
|
enum strata to_stratum;
|
93 |
|
|
struct target_ops
|
94 |
|
|
*DONT_USE; /* formerly to_next */
|
95 |
|
|
int to_has_all_memory;
|
96 |
|
|
int to_has_memory;
|
97 |
|
|
int to_has_stack;
|
98 |
|
|
int to_has_registers;
|
99 |
|
|
int to_has_execution;
|
100 |
|
|
struct section_table
|
101 |
|
|
*to_sections;
|
102 |
|
|
struct section_table
|
103 |
|
|
*to_sections_end;
|
104 |
|
|
int to_magic;
|
105 |
|
|
/* Need sub-structure for target machine related rather than comm related? */
|
106 |
|
|
@};
|
107 |
|
|
@end example
|
108 |
|
|
|
109 |
|
|
This structure contains pointers to functions (in C++, this would
|
110 |
|
|
be called a virtual class). Each different target supported by GDB has its own
|
111 |
|
|
structure with the relevant implementation of the functions (some functions
|
112 |
|
|
may be not implemented). When a user connects GDB to a target via the ``target''
|
113 |
|
|
command, GDB points to the structure corresponding to this target. Then the
|
114 |
|
|
user can attache GDB to a specific task via the ``attach'' command. We have
|
115 |
|
|
therefore identified two steps to begin a remote debug session :
|
116 |
|
|
|
117 |
|
|
@enumerate
|
118 |
|
|
@item the choice of the target type (in our case RTEMS),
|
119 |
|
|
@item the choice of what to debug (entire system, specific task,...),
|
120 |
|
|
@end enumerate
|
121 |
|
|
Note that in the case of natives debugger, the choice of the target is implicitly
|
122 |
|
|
performed by commands like @b{run}, @b{attach}, @b{detach}. Several
|
123 |
|
|
figures will now be described showing the main steps of a debug session.
|
124 |
|
|
|
125 |
|
|
@c XXX figure reference
|
126 |
|
|
Figure @b{Debug session initialization} explains how the debugger connects to the target
|
127 |
|
|
:
|
128 |
|
|
|
129 |
|
|
@enumerate
|
130 |
|
|
@item The debugger opens a connection to the target. The word ``connection''
|
131 |
|
|
doesn't only mean Ethernet or serial link connection but all the ways by which
|
132 |
|
|
a process can communicate with another one (direct function call, messages mailbox,
|
133 |
|
|
...),
|
134 |
|
|
@item The targets checks if it can accept or reject this connection,
|
135 |
|
|
@item If the connection is accepted, the host ``attaches'' the process,
|
136 |
|
|
@item the target stops the process, notifies a child's stop to the host
|
137 |
|
|
and waits for command,
|
138 |
|
|
@item the host can ask information about the debugged process (name, registers,...)
|
139 |
|
|
or perform some action like setting breakpoints, ...
|
140 |
|
|
@end enumerate
|
141 |
|
|
|
142 |
|
|
@c XXX figure reference
|
143 |
|
|
Figure @b{Breakpoint and process execution} explains how the debugger manages the
|
144 |
|
|
breakpoints and controls the execution of a process :
|
145 |
|
|
|
146 |
|
|
@enumerate
|
147 |
|
|
@item The host asks the debuggee what is the opcode at the concerned address
|
148 |
|
|
in order for GDB to memorize this instruction,
|
149 |
|
|
@item the host sends a CONTINUE command : it asks the target to write the
|
150 |
|
|
``DEBUG'' opcode (for example, the INTEL ``DEBUG'' opcode is INT3 which
|
151 |
|
|
generate a breakpoint trap) instead of the debugged opcode.
|
152 |
|
|
@item then the host waits for events,
|
153 |
|
|
@item after the change of instruction, the target resumes the execution
|
154 |
|
|
of the debuggee,
|
155 |
|
|
@item when the ``DEBUG'' opcode is executed, the breakpoint exception
|
156 |
|
|
handler is executed and it notifies the host that the process is stopped. Then
|
157 |
|
|
it waits for commands (if no command is sent after a certain amount of time,
|
158 |
|
|
the connection will be closed by the target).
|
159 |
|
|
@item the host asks the target to re-write the right opcode instead of the
|
160 |
|
|
''DEBUG'' opcode and then can ask information
|
161 |
|
|
@end enumerate
|
162 |
|
|
|
163 |
|
|
@c XXX figure reference
|
164 |
|
|
Figure @b{Breakpoint and process execution} also shows the case of other ``CONTINUE''
|
165 |
|
|
commands (remember that the ``DEBUG'' opcode has been replaced by the right
|
166 |
|
|
instruction):
|
167 |
|
|
|
168 |
|
|
@enumerate
|
169 |
|
|
@item Host sends first a ``single step'' command to execute the debugged
|
170 |
|
|
instruction,
|
171 |
|
|
@item It then waits for ``single step`` exception event,
|
172 |
|
|
@item the target, once the single step executed, calls the debug exception
|
173 |
|
|
handler. It notifies the host that execution is suspended and wait for commands.
|
174 |
|
|
@item the host asks the target to re-write the ``DEBUG'' opcode (breakpoint
|
175 |
|
|
trap) instead of the debugged one.
|
176 |
|
|
@item then the host sends a ``CONTINUE'' command in order the target to
|
177 |
|
|
resume the process execution to the next breakpoint.
|
178 |
|
|
@end enumerate
|
179 |
|
|
|
180 |
|
|
@c XXX figure reference
|
181 |
|
|
Figure @b{Detach a process and close a connection} explains how the debugger disconnects from
|
182 |
|
|
a target :
|
183 |
|
|
|
184 |
|
|
@enumerate
|
185 |
|
|
@item the host sends a detach command to the target.
|
186 |
|
|
@item the target detaches the concerned process, notifies the detachment
|
187 |
|
|
and resumes the process execution.
|
188 |
|
|
@item once notified, the host sends a close connection command.
|
189 |
|
|
@item the target closes the connection.
|
190 |
|
|
@end enumerate
|
191 |
|
|
These 3 examples show that the mains actions that are performed by
|
192 |
|
|
the host debugger on the target are only simple actions which look like :
|
193 |
|
|
|
194 |
|
|
@itemize @bullet
|
195 |
|
|
@item read/write code,
|
196 |
|
|
@item read/write data,
|
197 |
|
|
@item read/write registers,
|
198 |
|
|
@item manage exceptions,
|
199 |
|
|
@item send/receive messages to/from the host.
|
200 |
|
|
@end itemize
|
201 |
|
|
|
202 |
|
|
|
203 |
|
|
@c
|
204 |
|
|
@c Debug session initialization Figure
|
205 |
|
|
@c
|
206 |
|
|
|
207 |
|
|
@ifset use-ascii
|
208 |
|
|
@example
|
209 |
|
|
@group
|
210 |
|
|
XXXXX reference it in the previous paragraph
|
211 |
|
|
XXXXX insert seqinit.eps
|
212 |
|
|
XXXXX Caption Debug session initialization
|
213 |
|
|
@end group
|
214 |
|
|
@end example
|
215 |
|
|
@end ifset
|
216 |
|
|
|
217 |
|
|
@ifset use-tex
|
218 |
|
|
@example
|
219 |
|
|
@group
|
220 |
|
|
@c XXXXX reference it in the previous paragraph
|
221 |
|
|
@c XXXXX insert seqinit.eps
|
222 |
|
|
@c XXXXX Caption Debug session initialization
|
223 |
|
|
@end group
|
224 |
|
|
@end example
|
225 |
|
|
@page
|
226 |
|
|
@image{seqinit}
|
227 |
|
|
@end ifset
|
228 |
|
|
|
229 |
|
|
|
230 |
|
|
@ifset use-html
|
231 |
|
|
@c ![Debug session initialization](seqinit.jpg)
|
232 |
|
|
@html
|
233 |
|
|
![Debug session initialization](seqinit.jpg)
|
234 |
|
|
@end html
|
235 |
|
|
@end ifset
|
236 |
|
|
|
237 |
|
|
|
238 |
|
|
@c
|
239 |
|
|
@c Breakpoint and process execution Figure
|
240 |
|
|
@c
|
241 |
|
|
|
242 |
|
|
@ifset use-ascii
|
243 |
|
|
@example
|
244 |
|
|
@group
|
245 |
|
|
XXXXX reference it in the previous paragraph
|
246 |
|
|
XXXXX insert seqbreak.eps
|
247 |
|
|
XXXXX Caption Breakpoint and process execution
|
248 |
|
|
@end group
|
249 |
|
|
@end example
|
250 |
|
|
@end ifset
|
251 |
|
|
|
252 |
|
|
@ifset use-tex
|
253 |
|
|
@example
|
254 |
|
|
@group
|
255 |
|
|
@c XXXXX reference it in the previous paragraph
|
256 |
|
|
@c XXXXX insert seqbreak.eps
|
257 |
|
|
@c XXXXX Caption Breakpoint and process execution
|
258 |
|
|
@end group
|
259 |
|
|
@end example
|
260 |
|
|
@page
|
261 |
|
|
@sp 5
|
262 |
|
|
@image{seqbreak,,9in}
|
263 |
|
|
@end ifset
|
264 |
|
|
|
265 |
|
|
@ifset use-html
|
266 |
|
|
@c ![Breakpoint and process execution](seqbreak.jpg)
|
267 |
|
|
@html
|
268 |
|
|
![Breakpoint and process execution](seqbreak.jpg)
|
269 |
|
|
@end html
|
270 |
|
|
@end ifset
|
271 |
|
|
|
272 |
|
|
|
273 |
|
|
|
274 |
|
|
@c
|
275 |
|
|
@c Detach a process and close a connection Figure
|
276 |
|
|
@c
|
277 |
|
|
|
278 |
|
|
@ifset use-ascii
|
279 |
|
|
@example
|
280 |
|
|
@group
|
281 |
|
|
XXXXX reference it in the previous paragraph
|
282 |
|
|
XXXXX insert seqdetach.eps
|
283 |
|
|
XXXXX Caption Detach a process and close a connection
|
284 |
|
|
@end group
|
285 |
|
|
@end example
|
286 |
|
|
@end ifset
|
287 |
|
|
|
288 |
|
|
@ifset use-tex
|
289 |
|
|
@example
|
290 |
|
|
@group
|
291 |
|
|
@c XXXXX reference it in the previous paragraph
|
292 |
|
|
@c XXXXX insert seqdetach.eps
|
293 |
|
|
@c XXXXX Caption Detach a process and close a connection
|
294 |
|
|
@end group
|
295 |
|
|
@end example
|
296 |
|
|
@sp 10
|
297 |
|
|
@image{seqdetach}
|
298 |
|
|
@end ifset
|
299 |
|
|
|
300 |
|
|
@ifset use-html
|
301 |
|
|
@c ![Detach a process and close a connection](seqdetach.jpg)
|
302 |
|
|
@html
|
303 |
|
|
![Detach a process and close a connection](seqdetach.jpg)
|
304 |
|
|
@end html
|
305 |
|
|
@end ifset
|
306 |
|
|
|
307 |
|
|
|
308 |
|
|
|
309 |
|
|
|