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 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 <IMG SRC="layers.jpg" WIDTH=500 HEIGHT=600 ALT="Communications Layers"> |
---|
108 | @html |
---|
109 | <IMG SRC="layers.jpg" ALT="Communications Layers"> |
---|
110 | @end html |
---|
111 | @end ifset |
---|
112 | |
---|
113 | |
---|
114 | |
---|
115 | |
---|