source: rtems/doc/rgdb_specs/gdbinternals.t @ defc332

4.104.114.84.95
Last change on this file since defc332 was defc332, checked in by Joel Sherrill <joel.sherrill@…>, on 10/06/99 at 17:48:01

Enabled images. Works pretty well for PostScript?. Ghostview does
not like the generated pdf but who knows what that really means.

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