Can now produce html, info, and PostScript without errors. Links

between chapters are correct.

doc/rgdb_specs/Makefile

@@ -61,42 +61,42 @@ clean:
 #
 
 intro.texi: intro.t Makefile
-	$(BMENU) -p "Top" \
+	$(BMENU) -c -p "Top" \
 	    -u "Top" \
-	    -n "" ${*}.t
+	    -n "Document Revision History" ${*}.t
 
 revision.texi: revision.t Makefile
-	$(BMENU) -p "Top" \
+	$(BMENU) -c -p "Introduction" \
 	    -u "Top" \
-	    -n "" ${*}.t
+	    -n "Objectives" ${*}.t
 
 objectives.texi: objectives.t Makefile
-	$(BMENU) -p "Top" \
+	$(BMENU) -c -p "Document Revision History" \
 	    -u "Top" \
-	    -n "" ${*}.t
+	    -n "A Rapid Tour of GDB Internals" ${*}.t
 
 gdbinternals.texi: gdbinternals.t Makefile
-	$(BMENU) -p "Top" \
+	$(BMENU) -c -p "Implied Restrictions" \
 	    -u "Top" \
-	    -n "" ${*}.t
+	    -n "Interfacing GDB with RTEMS as a Target" ${*}.t
 
 interfacing.texi: interfacing.t Makefile
-	$(BMENU) -p "Top" \
+	$(BMENU) -c -p "A Rapid Tour of GDB Internals" \
 	    -u "Top" \
-	    -n "" ${*}.t
+	    -n "Communication with GDB" ${*}.t
 
 comm.texi: comm.t Makefile
-	$(BMENU) -p "Top" \
+	$(BMENU) -c -p "Interfacing GDB with RTEMS as a Target" \
 	    -u "Top" \
-	    -n "" ${*}.t
+	    -n "RTEMS Debugger Server Daemon" ${*}.t
 
 daemon.texi: daemon.t Makefile
-	$(BMENU) -p "Top" \
+	$(BMENU) -c -p "Communication with GDB" \
 	    -u "Top" \
-	    -n "" ${*}.t
+	    -n "Conclusion" ${*}.t
 
 conclusion.texi: conclusion.t Makefile
-	$(BMENU) -p "Top" \
+	$(BMENU) -c -p "Output of a Debug Session with the Prototype" \
 	    -u "Top" \
 	    -n "" ${*}.t
 

doc/rgdb_specs/comm.t

@@ -4,7 +4,7 @@
 @c  Written by: Eric Valette <valette@crf.canon.fr>
 @c              Emmanuel Raguet <raguet@crf.canon.fr>
 @c
-@C
+@c
 @c  $Id$
 @c
 

doc/rgdb_specs/daemon.t

@@ -17,7 +17,7 @@ and we will use an Ethernet link to communicate between the host and the target.
 The RTEMS remote debugger will be composed by several tasks and exception
 handlers :
 
-@itemize @b
+@itemize @bullet
 @item an initialization task which opens the sockets and runs the SUN RPC
 server. This task will also connect the interrupt handlers and launch the communication
 task
@@ -47,12 +47,12 @@ in the section @b{Open Issues}. The temporary workaround we chose are described
 in chapter @b{Workarounds for Open Issues in Prototype}.
 
 
-@subsection The INITIALIZATION task
+@section The INITIALIZATION task
 
 This is the task that must be executed at the boot phase of RTEMS.
 It initializes the debug context. It must :
 
-@itemize @b
+@itemize @bullet
 @item open the UDP sockets,
 @item run the SUN RPC server main loop,
 @item create the COMMAND MANAGEMENT task,
@@ -64,7 +64,7 @@ If an error occurs at any step of the execution, the connections established
 before the error will be closed, before the initialization task deletes itself.
 
 
-@subsection The COMMAND_MNGT task
+@section The COMMAND_MNGT task
 
 This task is in charge of receiving the SUN RPC messages and executing
 the associated commands. This task must have an important priority because it
@@ -86,7 +86,7 @@ case the COMMAND_MNGT task creates the EVENT_MNGT task described below before
 going to wait on UDP socket again.
 
 
-@subsection The EVENT_MNGT task
+@section The EVENT_MNGT task
 
 This task is in charge of managing events happening on the debuggee such as
 breakpoint, exceptions. This task does a basic simple loop waiting for event
@@ -95,12 +95,12 @@ then signals GDB that an event occurred and then go sleeping again as further
 requests will be processed by the COMMAND_MNGT task.
 
 
-@subsection The DEBUG EXCEPTION handler
+@section The DEBUG EXCEPTION handler
 
 This handler is connected to the DEBUG exception (INT 1 on Intel ix86).
 This exception is entered when :
 
-@itemize @b
+@itemize @bullet
 @item executing a single-step instruction,
 @item hardware breakpoint condition is true,
 @end itemize
@@ -110,7 +110,7 @@ cases, the DEBUG EXCEPTION handler code is executed. Please note that the execut
 context of the exception handler is the supervisor stack of the task that generated
 the exception . This implies :
 
-@itemize @b
+@itemize @bullet
 @item We may sleep in this context,
 @item We have as many possible execution context for the DEBUG EXCEPTION handler as
 we need to,
@@ -128,7 +128,7 @@ receive a PTRACE_CONT command it will resume the execution of the task that
 caused the exception by doing a V on the synchronization object. 
 
 
-@subsection The BREAKPOINT EXCEPTION handler
+@section The BREAKPOINT EXCEPTION handler
 
 This handler is connected to the BREAKPOINT exception (INT3 on Intel
 Ix86). Each time the debugger wants to place a software breakpoint in the debuggee,
@@ -138,14 +138,14 @@ the BREAKPOINT handler is executed. Otherwise, the exception processing is the
 same than the one described in previous section.
 
 
-@subsection Synchronization Among Tasks and Exception Handlers
+@section Synchronization Among Tasks and Exception Handlers
 
 The previous chapters have presented a simplified and static view of the various
 tasks and exceptions handlers. This chapter is more focussed on synchronization
 requirements about the various pieces of code executed when RGDBSD is operating.
 
 
-@subsubsection Implicit Synchronization Using Task Priorities
+@subsection Implicit Synchronization Using Task Priorities
 
 This chapter is relevant on Uniprocessor System (UP) only. However, it will
 also list the requirements for explicit synchronization on Multi-processor Systems
@@ -170,7 +170,7 @@ queues, task to processor binding for non symmetric IO, use a different implemen
 for @emph{task_disable_preemption}, ...
 
 
-@subsubsection Explicit Synchronization
+@subsection Explicit Synchronization
 
 This chapter will describe the synchronization variables that need to be implemented
 in order to sequence debug events in a way that is compatible with what GDB
@@ -190,12 +190,12 @@ requirements. Here is the list of synchronization variables we plan to use and
 their usage. They are all regular semaphores. They are not binary semaphores
 because the task that does V is not the task that has done the P.
 
-@itemize @b
+@itemize @bullet
 @item @emph{WakeUpEventTask} : used by exception handler code to wake up the EVENT_MNGT
 task by doing a V operation on this object. When target code is running normally
 the EVENT_MNGT task sleeps due to a P operation on this semaphore,
 @item @emph{SerializeDebugEvent} : used to serialize events in a way compatible to
-what GDB expects. Before doing a V operation on @emph{WakeUpEventTask,} the
+what GDB expects. Before doing a V operation on @emph{WakeUpEventTask}, the
 exception handler does a P on this semaphore to be sure processing of another
 exception is not in progress. Upon reception of a CONTINUE command, the COMMAND_MNGT
 task will issue a V operation so that the exception code can wake up EVENT_MNGT
@@ -211,7 +211,7 @@ the program avoiding any loop. So not special analysis of cause of exception
 is foreseen as far as RGDBSD code is concerned,
 @end itemize
 
-@subsection Open Issues
+@section Open Issues
 
 Here are some problems we have faced while implementing our prototype :
 
@@ -223,7 +223,7 @@ task. It shall not enter the default exception handler set by RGDBSD or it will
 cause a dead lock in the RGDBSD code. Replacing the default exception vector
 before calling @b{readMem/writeMem} can be temporarily sufficient but :
 
-@itemize @b
+@itemize @bullet
 @item It will never work on MP system as it will rely on task priorities to insure
 that other task will not cause exceptions while we have removed the default
 exception handler,
@@ -248,7 +248,7 @@ that the target task is in a stopped state and that it can restart it using
 the regular CONTINUE command. In RTEMS there is a way to get force a thread
 to become inactive via @emph{rtems_task_suspend} but no way to get the full
 registers set for the thread. A partial context can be retrieved from the task
-@emph{Registers} data structure. On the other hand, relying on @emph{rtems_task_suspend
+@emph{Registers} data structure. On the other hand, relying on @emph{rtems_task_suspend}
 will be a problem for the nano-kernel implementation.
 
 @item [Stopping Target System (I3)]:
@@ -301,7 +301,7 @@ gracefully terminate as GDB does not find some backtrace termination condition
 it expects.
 @end table
 
-@subsection Workarounds for Open Issues in Prototype
+@section Workarounds for Open Issues in Prototype
 
 @table @b
 
@@ -337,7 +337,7 @@ in the path to really starts the task for the first time. The processor/system
 specific stop condition can be found as macros in the GDB source tree.
 @end table
 
-@subsection Output of a Debug Session with the Prototype
+@section Output of a Debug Session with the Prototype
 
 @example
 GNU gdb 4.17
@@ -391,7 +391,7 @@ Breakpoint 1, example2 (argument=4) at /rtems/c/src/tests/samples/debug/init.c:8
 Breakpoint 2 at 0x200128: file /rtems/c/src/tests/samples/debug/init.c, line 66.
 (gdb) c
 Continuing. 
-{Switching to Rtems thread 134283270 (Not suspended) ( <= current target thread )]
+Switching to Rtems thread 134283270 (Not suspended) ( <= current target thread )]
 Breakpoint 2, example1 (argument=4) at /rtems/c/src/tests/samples/debug/init.c:66 
 66          toto += titi; 
 (gdb) c 

doc/rgdb_specs/gdbinternals.t

@@ -119,7 +119,7 @@ Note that in the case of natives debugger, the choice of the target is implicitl
 performed by commands like @b{run}, @b{attach}, @b{detach}. Several
 figures will now be described showing the main steps of a debug session. 
 
-@C XXX figure reference
+@c XXX figure reference
 Figure @b{Debug session initialization} explains how the debugger connects to the target
 :
 
@@ -136,7 +136,7 @@ and waits for command,
 or perform some action like setting breakpoints, ...
 @end enumerate
 
-@C XXX figure reference
+@c XXX figure reference
 Figure @b{Breakpoint and process execution} explains how the debugger manages the
 breakpoints and controls the execution of a process :
 
@@ -157,7 +157,7 @@ the connection will be closed by the target).
 ''DEBUG'' opcode and then can ask information
 @end enumerate
 
-@C XXX figure reference
+@c XXX figure reference
 Figure @b{Breakpoint and process execution} also shows the case of other ``CONTINUE''
 commands (remember that the ``DEBUG'' opcode has been replaced by the right
 instruction): 
@@ -174,7 +174,7 @@ trap) instead of the debugged one.
 resume the process execution to the next breakpoint.
 @end enumerate
 
-@C XXX figure reference
+@c XXX figure reference
 Figure @b{Detach a process and close a connection} explains how the debugger disconnects from
 a target :
 
@@ -188,7 +188,7 @@ and resumes the process execution.
 These 3 examples show that the mains actions that are performed by
 the host debugger on the target are only simple actions which look like :
 
-@itemize @b
+@itemize @bullet
 @item read/write code,
 @item read/write data,
 @item read/write registers,

doc/rgdb_specs/interfacing.t

@@ -10,7 +10,7 @@
 
 @chapter Interfacing GDB with RTEMS as a Target
 
-@C XXX figure reference
+@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.
@@ -29,7 +29,7 @@ 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 @b
+@itemize @bullet
 @item set up a connection with a target,
 @item close a connection,
 @item send a signal to the specified process,
@@ -45,7 +45,7 @@ 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 @b
+@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,
@@ -59,7 +59,7 @@ 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 @b
+@itemize @bullet
 @item get current task registers,
 @item set current task registers,
 @item list of the threads,

doc/rgdb_specs/objectives.t

@@ -10,7 +10,7 @@
 
 @chapter Objectives
 
-@C XXX reference
+@c XXX reference
 This section is intended to clearly define the current objectives of our work.
 First, we will try here to list some ambitious requirements for the debugger
 in section @b{List of Requirements}. These requirements will deliberately be much more
@@ -25,7 +25,7 @@ chose to implement and the ones we will not. We will then clearly identify the
 limits of our solution in section @b{Implied Restrictions}.
 
 
-@subsection List of Requirements
+@section List of Requirements
 
 We will identify here possible requirements for the type of debug that may be
 provided :
@@ -72,7 +72,7 @@ so that debugging a particular portion of code does not prevent another part
 from functioning,
 @end table
 
-@subsection Requirements Analysis
+@section Requirements Analysis
 
 @table @b
 
@@ -80,7 +80,7 @@ from functioning,
 Worth recalling it. It mainly imposes few restrictions on the binary
 files type, target processor type as :
 
-@itemize @b
+@itemize @bullet
 
 @item the binary format must be understood by GDB (to find debugging information).
 Elf, Coff and A.out are the main formats currently supported. Elf/Dwarf 2.0
@@ -214,10 +214,10 @@ This requirement heavily depends on the @b{(R7)} and @b{(R8)}
 requirements.
 @end table
 
-@subsection Requirements Selection
+@section Requirements Selection
 
 
-@subsubsection Requirement We Will Take Into Account For the First Implementation
+@subsection Requirement We Will Take Into Account For the First Implementation
 
 @table @b
 
@@ -244,7 +244,7 @@ once we have the RGDBSD code,
 We will try to provide the multi-thread target system presentation,
 @end table
 
-@subsubsection Requirements We Will Not Implement
+@subsection Requirements We Will Not Implement
 
 @table @b
 
@@ -276,11 +276,11 @@ Without a separate TCP/IP stack it will be hard to freeze the system
 as some interrupts must occur in order to enable the FreeBSD stack to function,
 @end table
 
-@subsection Implied Restrictions
+@section Implied Restrictions
 
 High priority level must be used for these features :
 
-@itemize @b
+@itemize @bullet
 
 @item FreeBSD interrupt handling thread,
 
@@ -293,7 +293,7 @@ in debug mode
 If we don't want to use a ``specific'' priority level, we must affect
 priority to each of these tasks as follow :
 
-@itemize @b
+@itemize @bullet
 
 @item FreeBSD stack (high priority)
 

doc/rgdb_specs/revision.t

@@ -10,26 +10,32 @@
 
 @chapter Document Revision History
 
-@ubaraccent{Current release} : 
+@b{Current release} : 
 
-@itemize @b
+@itemize @bullet
 @item Current applicable release is 2.0.
 @end itemize
-@ubaraccent{Existing releases} :
 
-@itemize @b
+@b{Existing releases} :
+
+@itemize @bullet
 @item 0.1 : Released the 29/09/98. First draft of this document.
+
 @item 0.2 : Released the 05/10/98. Second draft version.
+
 @item 1.0 : Released the 08/10/98. Version Approved internally.
+
 @item 1.1 : Released the 13/13/98. Version Distributed for comments.
+
 @item 2.0 : Released the 01/11/98. Version including modifications related
 to comments we have got from the RTEMS mailing list. It also contains a
 more precise description of RGDBSD as we now have a first prototype,
+
 @end itemize
 
-@ubaraccent{Planned releases} :
+@b{Planned releases} :
 
-@itemize @b
+@itemize @bullet
 @item 2.1 Final specification release intended to include a second round
 of comments,
 @end itemize