mingw/info/gdbint/Target-Vector-Definition.html

   1 <html lang="en">
   2 <head>
   3 <title>GDB Internals</title>
   4 <meta http-equiv="Content-Type" content="text/html">
   5 <meta name="description" content="GDB Internals">
   6 <meta name="generator" content="makeinfo 4.3">
   7 <link href="http://www.gnu.org/software/texinfo/" rel="generator-home">
   8 </head>
   9 <body>
  10 <div class="node">
  11 <p>
  12 Node:<a name="Target%20Vector%20Definition">Target Vector Definition</a>,
  13 Next:<a rel="next" accesskey="n" href="Native-Debugging.html#Native%20Debugging">Native Debugging</a>,
  14 Previous:<a rel="previous" accesskey="p" href="Target-Architecture-Definition.html#Target%20Architecture%20Definition">Target Architecture Definition</a>,
  15 Up:<a rel="up" accesskey="u" href="index.html#Top">Top</a>
  16 <hr><br>
  17 </div>
  18
  19 <h2 class="chapter">Target Vector Definition</h2>
  20
  21    <p>The target vector defines the interface between GDB's
  22 abstract handling of target systems, and the nitty-gritty code that
  23 actually exercises control over a process or a serial port.
  24 GDB includes some 30-40 different target vectors; however,
  25 each configuration of GDB includes only a few of them.
  26
  27 <h3 class="section">File Targets</h3>
  28
  29    <p>Both executables and core files have target vectors.
  30
  31 <h3 class="section">Standard Protocol and Remote Stubs</h3>
  32
  33    GDB's file <code>remote.c</code> talks a serial protocol to code
  34 that runs in the target system.  GDB provides several sample
  35 <dfn>stubs</dfn> that can be integrated into target programs or operating
  36 systems for this purpose; they are named <code>*-stub.c</code>.
  37
  38    <p>The GDB user's manual describes how to put such a stub into
  39 your target code.  What follows is a discussion of integrating the
  40 SPARC stub into a complicated operating system (rather than a simple
  41 program), by Stu Grossman, the author of this stub.
  42
  43    <p>The trap handling code in the stub assumes the following upon entry to
  44 <code>trap_low</code>:
  45
  46      <ol type=1 start=1>
  47 <li>%l1 and %l2 contain pc and npc respectively at the time of the trap;
  48
  49      <li>traps are disabled;
  50
  51      <li>you are in the correct trap window.
  52         </ol>
  53
  54    <p>As long as your trap handler can guarantee those conditions, then there
  55 is no reason why you shouldn't be able to "share" traps with the stub.
  56 The stub has no requirement that it be jumped to directly from the
  57 hardware trap vector.  That is why it calls <code>exceptionHandler()</code>,
  58 which is provided by the external environment.  For instance, this could
  59 set up the hardware traps to actually execute code which calls the stub
  60 first, and then transfers to its own trap handler.
  61
  62    <p>For the most point, there probably won't be much of an issue with
  63 "sharing" traps, as the traps we use are usually not used by the kernel,
  64 and often indicate unrecoverable error conditions.  Anyway, this is all
  65 controlled by a table, and is trivial to modify.  The most important
  66 trap for us is for <code>ta 1</code>.  Without that, we can't single step or
  67 do breakpoints.  Everything else is unnecessary for the proper operation
  68 of the debugger/stub.
  69
  70    <p>From reading the stub, it's probably not obvious how breakpoints work.
  71 They are simply done by deposit/examine operations from GDB.
  72
  73 <h3 class="section">ROM Monitor Interface</h3>
  74
  75 <h3 class="section">Custom Protocols</h3>
  76
  77 <h3 class="section">Transport Layer</h3>
  78
  79 <h3 class="section">Builtin Simulator</h3>
  80
  81    </body></html>
  82