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 comm.t,v 1.5 2002/01/17 21:47:46 joel Exp
|
9 |
|
|
@c
|
10 |
|
|
|
11 |
|
|
@chapter Communication with GDB
|
12 |
|
|
|
13 |
|
|
The RTEMS remote debugger will be accessed by GDB on a host machine
|
14 |
|
|
through a communication link. We will use the TCP/IP stack included in RTEMS
|
15 |
|
|
: the FreeBSD stack. The communication link will be based based on the UDP protocol
|
16 |
|
|
and the BSD sockets which are parts of the FreeBSD stack. On top of these layers,
|
17 |
|
|
we will plug a module which allows a simple communication between different
|
18 |
|
|
machines (especially between different endianess machines) : the SUN Remote
|
19 |
|
|
Procedure Call (SUN RPC). This code is freely available on the net and comes
|
20 |
|
|
with a BSD like license. With this module, a process can invoke a procedure
|
21 |
|
|
on a remote system. The RTEMS remote debugger will be seen by GDB as a SUN RPC
|
22 |
|
|
server. Commands will be packed by the GDB SUN RPC client and sent to the server.
|
23 |
|
|
This server will unpack these commands, execute them and, if needed, return
|
24 |
|
|
results to the SUN RPC client.
|
25 |
|
|
|
26 |
|
|
|
27 |
|
|
Only a minimal subset of the SUN RPC library must be implemented.
|
28 |
|
|
For example, the portmapper related API which allows a dynamic allocation of
|
29 |
|
|
port numbers will not be implemented and some specific UDP port numbers will
|
30 |
|
|
be used to establish the communication between the host and the target. The
|
31 |
|
|
SUN RPC library implements the XDR module (eXternal Data Representation) which
|
32 |
|
|
is a standard way of encoding data in a portable fashion between different endian
|
33 |
|
|
systems. Below are figures describing the additional code and data size for
|
34 |
|
|
the minimal library implementation we currently have already implemented for
|
35 |
|
|
RTEMS :
|
36 |
|
|
|
37 |
|
|
@example
|
38 |
|
|
$ size -x librpc.a
|
39 |
|
|
text data bss dec hex filename
|
40 |
|
|
0x40e 0x0 0x0 1038 40e rpc_callmsg.o (ex librpc.a)
|
41 |
|
|
0x2f1 0x18 0x0 777 309 rpc_prot.o (ex librpc.a)
|
42 |
|
|
0x458 0x0 0x0 1112 458 svc.o (ex librpc.a)
|
43 |
|
|
0x4f 0x4 0x0 83 53 svc_auth.o (ex librpc.a)
|
44 |
|
|
0x75c 0x18 0x0 1908 774 svc_udp.o (ex librpc.a)
|
45 |
|
|
0x711 0x4 0x10 1829 725 xdr.o (ex librpc.a)
|
46 |
|
|
0x149 0x0 0x0 329 149 xdr_array.o (ex librpc.a)
|
47 |
|
|
0x165 0x20 0x0 389 185 xdr_mem.o (ex librpc.a)
|
48 |
|
|
@end example
|
49 |
|
|
|
50 |
|
|
We have a constraint with the use of the UDP protocol. Because this
|
51 |
|
|
protocol is connectionless, it is impossible, especially for the target, to
|
52 |
|
|
detect if the connection is always active. On the other hand, using the TCP/IP
|
53 |
|
|
protocols seems to be heavy especially if we plan to implement a dedicated micro
|
54 |
|
|
stack for debug in the future. It can be a real problem to let the debugged
|
55 |
|
|
process stopped during a long time even if there is no more debugger connected
|
56 |
|
|
to the system. To avoid such a problem, the target must periodically test the
|
57 |
|
|
connection with the host on another way than the one used to receive the commands.
|
58 |
|
|
We must therefore open two communication ways so we need two fixed UDP port
|
59 |
|
|
numbers.
|
60 |
|
|
|
61 |
|
|
@enumerate
|
62 |
|
|
@item One port will be used by the debugger to send its commands to the
|
63 |
|
|
debugged process and to receive the result of these commands. View from the
|
64 |
|
|
remote debugger, this port will be called primary port. For this one, we choose
|
65 |
|
|
arbitrarily the port number 2000.
|
66 |
|
|
@item The other socket will be used as secondary port by the target to sometimes
|
67 |
|
|
test the connection between the host and the target. These tests will occur
|
68 |
|
|
in specific situations, when a process will be stopped on a breakpoint, single
|
69 |
|
|
step instruction or other means. This secondary port will also be used by the
|
70 |
|
|
target to signal any change in the behavior of a debugged process (stopped,
|
71 |
|
|
killed, waiting for,...). For the secondary port, we choose the port number
|
72 |
|
|
2010.
|
73 |
|
|
@end enumerate
|
74 |
|
|
|
75 |
|
|
These two port numbers are used by the remote debugger to open the
|
76 |
|
|
two communication sockets. GDB will use its own mean to choose its port numbers
|
77 |
|
|
(probably the Unix portmapper). The figure layer shows the different
|
78 |
|
|
layers we need to implement.
|
79 |
|
|
|
80 |
|
|
@c
|
81 |
|
|
@c Communications Layers Figure
|
82 |
|
|
@c
|
83 |
|
|
|
84 |
|
|
@ifset use-ascii
|
85 |
|
|
@example
|
86 |
|
|
@group
|
87 |
|
|
XXXXX reference it in the previous paragraph
|
88 |
|
|
XXXXX insert layers.eps
|
89 |
|
|
XXXXX Caption Communications Layers
|
90 |
|
|
@end group
|
91 |
|
|
@end example
|
92 |
|
|
@end ifset
|
93 |
|
|
|
94 |
|
|
@ifset use-tex
|
95 |
|
|
@example
|
96 |
|
|
@group
|
97 |
|
|
@c XXXXX reference it in the previous paragraph
|
98 |
|
|
@c XXXXX insert layers.eps
|
99 |
|
|
@c XXXXX Caption Communications Layers
|
100 |
|
|
@end group
|
101 |
|
|
@end example
|
102 |
|
|
@image{layers,,6in}
|
103 |
|
|
@end ifset
|
104 |
|
|
|
105 |
|
|
|
106 |
|
|
@ifset use-html
|
107 |
|
|
@c 
|
108 |
|
|
@html
|
109 |
|
|

|
110 |
|
|
@end html
|
111 |
|
|
@end ifset
|
112 |
|
|
|
113 |
|
|
|
114 |
|
|
|
115 |
|
|
|