From 00de6acc8cf39313d6f2a0858955f3a2afcb67c0 Mon Sep 17 00:00:00 2001 From: Joel Sherrill Date: Thu, 2 Aug 2007 14:59:16 +0000 Subject: 2007-08-02 Joel Sherrill * Makefile.am, configure.ac, develenv/direct.t: Remove RDBG. * rgdb_specs/.cvsignore, rgdb_specs/Makefile.am, rgdb_specs/comm.t, rgdb_specs/conclusion.t, rgdb_specs/daemon.t, rgdb_specs/gdbinternals.t, rgdb_specs/interfacing.t, rgdb_specs/intro.t, rgdb_specs/layers.eps, rgdb_specs/layers.jpg, rgdb_specs/layers.txt, rgdb_specs/objectives.t, rgdb_specs/process.eps, rgdb_specs/process.jpg, rgdb_specs/process.txt, rgdb_specs/revision.t, rgdb_specs/rgdb_specs.texi, rgdb_specs/seqbreak.eps, rgdb_specs/seqbreak.jpg, rgdb_specs/seqbreak.txt, rgdb_specs/seqdetach.eps, rgdb_specs/seqdetach.jpg, rgdb_specs/seqdetach.txt, rgdb_specs/seqinit.eps, rgdb_specs/seqinit.jpg, rgdb_specs/seqinit.txt, rtems_gdb/.cvsignore, rtems_gdb/Makefile.am, rtems_gdb/commands.t, rtems_gdb/example.t, rtems_gdb/intro.t, rtems_gdb/rtems_gdb.texi, rtems_gdb/started.t, rtems_gdb/swarch.t, rtems_gdb/trouble.t: Removed. --- doc/rgdb_specs/comm.t | 98 --------------------------------------------------- 1 file changed, 98 deletions(-) delete mode 100644 doc/rgdb_specs/comm.t (limited to 'doc/rgdb_specs/comm.t') diff --git a/doc/rgdb_specs/comm.t b/doc/rgdb_specs/comm.t deleted file mode 100644 index 3df3c18645..0000000000 --- a/doc/rgdb_specs/comm.t +++ /dev/null @@ -1,98 +0,0 @@ -@c -@c RTEMS Remote Debugger Server Specifications -@c -@c Written by: Eric Valette -@c Emmanuel Raguet -@c -@c -@c $Id$ -@c - -@chapter Communication with GDB - -The RTEMS remote debugger will be accessed by GDB on a host machine -through a communication link. We will use the TCP/IP stack included in RTEMS -: the FreeBSD stack. The communication link will be based based on the UDP protocol -and the BSD sockets which are parts of the FreeBSD stack. On top of these layers, -we will plug a module which allows a simple communication between different -machines (especially between different endianess machines) : the SUN Remote -Procedure Call (SUN RPC). This code is freely available on the net and comes -with a BSD like license. With this module, a process can invoke a procedure -on a remote system. The RTEMS remote debugger will be seen by GDB as a SUN RPC -server. Commands will be packed by the GDB SUN RPC client and sent to the server. -This server will unpack these commands, execute them and, if needed, return -results to the SUN RPC client. - - -Only a minimal subset of the SUN RPC library must be implemented. -For example, the portmapper related API which allows a dynamic allocation of -port numbers will not be implemented and some specific UDP port numbers will -be used to establish the communication between the host and the target. The -SUN RPC library implements the XDR module (eXternal Data Representation) which -is a standard way of encoding data in a portable fashion between different endian -systems. Below are figures describing the additional code and data size for -the minimal library implementation we currently have already implemented for -RTEMS : - -@example -$ size -x librpc.a -text data bss dec hex filename -0x40e 0x0 0x0 1038 40e rpc_callmsg.o (ex librpc.a) -0x2f1 0x18 0x0 777 309 rpc_prot.o (ex librpc.a) -0x458 0x0 0x0 1112 458 svc.o (ex librpc.a) -0x4f 0x4 0x0 83 53 svc_auth.o (ex librpc.a) -0x75c 0x18 0x0 1908 774 svc_udp.o (ex librpc.a) -0x711 0x4 0x10 1829 725 xdr.o (ex librpc.a) -0x149 0x0 0x0 329 149 xdr_array.o (ex librpc.a) -0x165 0x20 0x0 389 185 xdr_mem.o (ex librpc.a) -@end example - -We have a constraint with the use of the UDP protocol. Because this -protocol is connectionless, it is impossible, especially for the target, to -detect if the connection is always active. On the other hand, using the TCP/IP -protocols seems to be heavy especially if we plan to implement a dedicated micro -stack for debug in the future. It can be a real problem to let the debugged -process stopped during a long time even if there is no more debugger connected -to the system. To avoid such a problem, the target must periodically test the -connection with the host on another way than the one used to receive the commands. -We must therefore open two communication ways so we need two fixed UDP port -numbers. - -@enumerate -@item One port will be used by the debugger to send its commands to the -debugged process and to receive the result of these commands. View from the -remote debugger, this port will be called primary port. For this one, we choose -arbitrarily the port number 2000. -@item The other socket will be used as secondary port by the target to sometimes -test the connection between the host and the target. These tests will occur -in specific situations, when a process will be stopped on a breakpoint, single -step instruction or other means. This secondary port will also be used by the -target to signal any change in the behavior of a debugged process (stopped, -killed, waiting for,...). For the secondary port, we choose the port number -2010. -@end enumerate - -These two port numbers are used by the remote debugger to open the -two communication sockets. GDB will use its own mean to choose its port numbers -(probably the Unix portmapper). The figure layer shows the different -layers we need to implement. - -@c -@c Communications Layers Figure -@c - -@ifclear use-html -@image{layers,,6in,"Communications Layers"} -@end ifclear - - -@ifset use-html -@c Communications Layers -@html -Communications Layers -@end html -@end ifset - - - - -- cgit v1.2.3