path: root/doc/rgdb_specs/interfacing.t
diff options
authorJoel Sherrill <>2007-08-02 14:59:16 +0000
committerJoel Sherrill <>2007-08-02 14:59:16 +0000
commit00de6acc8cf39313d6f2a0858955f3a2afcb67c0 (patch)
treef2f4f2600a7b088fa5a6567a1a13c88b778f14c1 /doc/rgdb_specs/interfacing.t
parent0c640d3d882d4055ae7d339662dd63a1dc7d3d2c (diff)
2007-08-02 Joel Sherrill <>
*,, develenv/direct.t: Remove RDBG. * rgdb_specs/.cvsignore, rgdb_specs/, 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/, 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.
Diffstat (limited to 'doc/rgdb_specs/interfacing.t')
1 files changed, 0 insertions, 79 deletions
diff --git a/doc/rgdb_specs/interfacing.t b/doc/rgdb_specs/interfacing.t
deleted file mode 100644
index f10ccdf5e0..0000000000
--- a/doc/rgdb_specs/interfacing.t
+++ /dev/null
@@ -1,79 +0,0 @@
-@c RTEMS Remote Debugger Server Specifications
-@c Written by: Eric Valette <>
-@c Emmanuel Raguet <>
-@c $Id$
-@chapter Interfacing GDB with RTEMS as a Target
-@c XXX figure reference
-So, basically, porting GDB to RTEMS environment requires implementing
-the functions contained in the target_ops structure. The native debugger implementation
-(where the host machine is also the target one) uses direct function calls.
-For our needs (remote debugging), these functions must be implemented to support
-the encapsulation in UDP/IP layers and communications between different types
-of host machines : the best solution is use the SUN Remote Procedure Calls API
-(SUN RPC). This SUN RPC module will be explained below (see paragraph @b{Communication with GDB}).
-We can note that the functions described in the target_ops structure
-are high-level functions. The main reason is that GDB was designed in order
-to be able to use monitor firmware as a debug server. In the case of a Unix
-OS target, these high-level functions are implemented themselves using a lower
-level POSIX API. Because we want to simplify the code running on the target
-and decrease its size of this code, we propose to use the POSIX layer API used
-for the debug like @b{waitpid}, @b{ptrace}, ... Due to the GDB working
-mode and due to our requirements, we can establish here a non-exhaustive list
-of some commands required to implement the previously described functions :
-@itemize @bullet
-@item set up a connection with a target,
-@item close a connection,
-@item send a signal to the specified process,
-@item get a list of process/thread/connection running,
-@item control process under debug,
-@item ...
-@end itemize
-Control means that, with this function, we can read, write the memory
-of the debuggee, insert breakpoint to stop the process and resume the process
-execution. This command can be implemented by emulating in the RTEMS environment
-a Unix function called ``ptrace''. This function allows the control of a child
-process. The ``ptrace'' function has some sub-functions which are described
-below (some of these actions and standardized, the others are added due to our
-needs) :
-@itemize @bullet
-@item PTRACE_PEEKTEXT, PTRACE_PEEKDATA : read word at address,
-@item PTRACE_POKETEXT, PTRACE_POKEDATA :write word at address,
-@item PTRACE_CONT : restart after signal,
-@item PTRACE_KILL : send the child a SIGKILL to make it exit,
-@item PTRACE_SINGLESTEP : set the trap flag for single stepping,
-@item PTRACE_ATTACH : attach to the process specified,
-@item PTRACE_DETACH : detach a process that was previously attached.
-@end itemize
-This list only contains the command that are described in the ptrace
-Unix manpage. For some specific needs (debug of one task among several ones,
-register read/write,...), it is possible to create some special ptrace commands
-as described after :
-@itemize @bullet
-@item get current task registers,
-@item set current task registers,
-@item list of the threads,
-@item identifier of the target thread,
-@item restart to address,
-@item set breakpoint at address,
-@item clear breakpoint,
-@item get breakpoints,
-@item load dynamically a task,
-@item ...
-@end itemize
-This list is not exhaustive and can be increased due to the needs.
-All the described functions will not be implemented in a first version, only
-the strictly needed. If some commands are added, the modifications must be implemented
-both in RTEMS and in GDB.