Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
soc:2008:stefanha:project_plan:start [2008/05/21 00:02]
stefanha
soc:2008:stefanha:project_plan:start [2008/05/22 23:27]
stefanha
Line 14: Line 14:
  
 ==== Outline ==== ==== Outline ====
 +
 +=== The GDB Remote Protocol ===
 +The GNU Debugger (GDB) has support for remote debugging. ​ This lets users debug applications running on other machines or in special environments,​ like under virtualization. ​ Remote debugging works by speaking a simple protocol that carries checksummed packets of commands and replies.
 +
 +The protocol is extensible and most commands are optional. ​ A minimal GDB stub must implement the following commands:
 +  * Register read/​write. ​ These commands allow the debugger to get and set the state of the CPU.
 +  * Memory read/​write. ​ These commands allows the debugger to peek and poke memory, as well as set breakpoints.
 +  * Single-step and continue. ​ These commands control the execution of a program.
 +
 +Additional GDB protocol commands provide more advanced features, like hardware breakpoints,​ or optimizations of existing commands, like binary memory dumps for faster transfer.
 +
 +I will implement the minimal set of commands. ​ If we find that additional commands are useful in practice, I will also implement them.
 +
 +=== Execution Model ===
 +The GDB stub is interrupt-driven. ​ Control is transferred to the GDB stub when an exception occurs. ​ When not in the interrupt context, the GDB stub is inactive.
 +
 +Upon entering an interrupt context, the GDB stub notes the state of the registers and the exception that was raised. ​ This information is sent to the remote GDB.
 +
 +GDB displays its prompt and lets the user invoke commands. ​ In the meantime, the GDB stub holds control of gPXE and blocks on input until the remote GDB sends a command.
 +
 +Commands are processed in a loop by the GDB stub until a continue or step command is received. ​ These commands pass control back to gPXE by leaving the interrupt context.
 +
 +Note that this execution model makes the GDB stub a blocking, top-level thread of control in gPXE.  After discussion with mcb30, we decided that although this is the anticipated execution model, the GDB stub should not be written to assume blocking. ​ This makes it possible to support other modes of debugging later, like periodic memory dumps while the program runs.
  
 Only 32-bit protected mode support is planned. ​ The bulk of gPXE runs in 32-bit protected mode and gdb/​binutils support this mode well. Only 32-bit protected mode support is planned. ​ The bulk of gPXE runs in 32-bit protected mode and gdb/​binutils support this mode well.
  
-Several transports are supported by GDB including serialUDP, and TCP.  Serial ​is simple and serves as a good starting point.  ​UDP and TCP are more flexible but also more complex. ​ After discussion with mcb30, ​it looks like UDP is in scope and should ​be implemented.  ​I believe TCP is not a big win if UDP support is already ​in place.+=== Isolation === 
 +The GDB stub controls the execution of gPXEbut the GDB stub is part of gPXE.  ​This sounds recursive - and it is!  Therefore, care must be taken to isolate the GDB stub from gPXE.  ​If the GDB stub is not isolated, it can hang itself. ​ For example, ​if the GDB stub calls ''​strcmp()'',​ then placing a breakpoint inside ''​strcmp()''​ may lead to recursion ​in the GDB stub.
  
-The GDB stub will support memory ​and register read/write.  ​This includes ​support for breakpoint debugging.+The GDB stub must be designed to depend on as few gPXE functions as possible. ​ That way, as much of gPXE as possible remains debuggable. ​ This conflicts with code reuse, so we will have to keep an eye on this during development. 
 + 
 +=== Transports === 
 +Several transports are supported by GDB including serial, UDP, and TCP.  ​Serial is simple and serves as a good starting point. ​ UDP and TCP are more flexible but also more complex. ​ After discussion with mcb30, it looks like UDP is in scope and should be implemented. 
 + 
 +I believe TCP is not a big win if UDP support ​is already in place. ​ The problem with TCP is that it depends on the TCP/IP stack and therefore blacklists a lot of gPXE code for breakpoints,​ due to isolation issues discussed above.
  
 ==== Milestones and Timeline ==== ==== Milestones and Timeline ====
  
-  * Set up IDT and write interrupt handler. +  * **Week 1** 
-  * Decide on interface for GDB transports and refactor serial console code to support serving as a GDB transport. +    - Set up IDT and write interrupt handler. 
-  ​* ​Implement GDB protocol encoder and decoder. +  * **Week 2** 
-  * Implement memory read/write, including GDB scripts as tests. +    - Decide on interface for GDB transports and refactor serial console code to support serving as a GDB transport. 
-  ​* ​Implement register read/write, including GDB scripts as tests. +    ​- ​Implement GDB protocol encoder and decoder. 
-  * Implement continue and single-step,​ including GDB scripts as tests. +  * **Week 3** 
-  ​* ​Ensure ​that breakpoints are working, including GDB scripts as tests. +    - Implement memory read/write, including GDB scripts as tests. 
-  * Implement miscellaneous GDB protocol commands like detach/​kill,​ including GDB scripts as tests+    ​- ​Implement register read/write, including GDB scripts as tests. 
-  * Implement UDP transport. +  * **Week 4** 
-  * Documentation (how to debug, how to run tests). +    - Implement continue and single-step,​ including GDB scripts as tests. 
-  * (Possibly) implement TCP transport ​and support TCP listen sockets.+    ​- ​Ensure breakpoints are working, including GDB scripts as tests. 
 +  * **Week 5** 
 +    - Ensure source-level debugging works
 +  * **Week 6** 
 +    - Half-term buffer for any schedule slip. 
 +  * **Week 7** 
 +    - Implement UDP transport. 
 +  * **Week 8** 
 +    - Documentation (how to debug, how to run tests). 
 +  * **Week 9** 
 +    - Usability ​and testing. ​ Work with other gPXE developers, encourage remote GDB usage, fix issues.
   * (Possibly) support running as a gPXE process for memory peek/poke during execution.   * (Possibly) support running as a gPXE process for memory peek/poke during execution.
 +  * (Possibly) refactor PXE UDP to bypass IP stack?
 +  * (Possibly) implement TCP transport and support TCP listen sockets.
  
 ==== Reference links ==== ==== Reference links ====
  
   * [[http://​code.google.com/​soc/​2008/​etherboot/​appinfo.html?​csaid=13D4DE0EB18B0081|Google Summer of Code Application Information]]   * [[http://​code.google.com/​soc/​2008/​etherboot/​appinfo.html?​csaid=13D4DE0EB18B0081|Google Summer of Code Application Information]]
 +  * [[http://​sourceware.org/​gdb/​current/​onlinedocs/​gdb_33.html|GDB Remote Serial Protocol]]
   * [[http://​sourceware.org/​gdb/​current/​onlinedocs/​gdb_18.html#​SEC174|Debugging with GDB: Implementing a Remote Stub]]   * [[http://​sourceware.org/​gdb/​current/​onlinedocs/​gdb_18.html#​SEC174|Debugging with GDB: Implementing a Remote Stub]]
   * [[http://​sourceware.org/​cgi-bin/​cvsweb.cgi/​src/​gdb/​i386-stub.c?​rev=1.5&​content-type=text/​x-cvsweb-markup&​cvsroot=src|GDB'​s i386-stub.c]]   * [[http://​sourceware.org/​cgi-bin/​cvsweb.cgi/​src/​gdb/​i386-stub.c?​rev=1.5&​content-type=text/​x-cvsweb-markup&​cvsroot=src|GDB'​s i386-stub.c]]
- 
- 

QR Code
QR Code soc:2008:stefanha:project_plan:start (generated for current page)