Differences

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

--- soc:2008:stefanha:project_plan:start [2008/05/21 00:50]
stefanha
+++ soc:2008:stefanha:project_plan:start [2008/05/22 23:27] (current)
stefanha
@@ Line 25: / Line 25: @@
 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 start by implementing the minimal set of commands.  If we find that additional commands are useful in practice, I will also implement them.
+I will implement the minimal set of commands.  If we find that additional commands are useful in practice, I will also implement them.
-=== GDB Stub Execution Model ===
+=== Execution Model ===
-The GDB stub controls the execution of gPXE, but 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 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.
+=== Isolation ===
+The GDB stub controls the execution of gPXE, but 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 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.
+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 ====
-  * 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 UDP transport.
+    - Implement register read/write, including GDB scripts as tests.
-  * Documentation (how to debug, how to run tests).
+  * **Week 4**
-  * (Possibly) implement TCP transport and support TCP listen sockets.
+    - Implement continue and single-step, including GDB scripts as tests.
+    - 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) refactor PXE UDP to bypass IP stack?
+  * (Possibly) implement TCP transport and support TCP listen sockets.
 ==== Reference links ====

Trace:

Differences

Navigation

Search

Toolbox

QR Code