OpenCores
URL https://opencores.org/ocsvn/or1k/or1k/trunk

Subversion Repositories or1k

[/] [or1k/] [trunk/] [rtems-20020807/] [doc/] [rgdb_specs/] [gdbinternals.t] - Blame information for rev 1765

Details | Compare with Previous | View Log

Line No. Rev Author Line
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
232
@html
233
Debug session initialization
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
267
@html
268
Breakpoint and process execution
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
302
@html
303
Detach a process and close a connection
304
@end html
305
@end ifset
306
 
307
 
308
 
309
 

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.