Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
soc:2008:stefanha:journal:week2 [2008/06/05 12:10] stefanha |
soc:2008:stefanha:journal:week2 [2008/06/09 03:09] (current) stefanha |
||
|---|---|---|---|
| Line 70: | Line 70: | ||
| **GDB remote debugging is in mainline gPXE**. Thanks to mcb30 for reviewing and merging the code. | **GDB remote debugging is in mainline gPXE**. Thanks to mcb30 for reviewing and merging the code. | ||
| - | Documentation is available [[:dev:gdbstub|here]]. I also spent a couple of hours yesterday and today making a [[http://video.google.com/videoplay?docid=-5951365569769661989&hl=en|screencast]] ([[http://etherboot.org/share/stefanha/gdbstub.mpeg|higher quality version]] 12 MB): | + | Documentation is available [[:dev:gdbstub|here]]. I also spent a couple of hours yesterday and today making a [[http://video.google.com/videoplay?docid=-5951365569769661989&hl=en|screencast]] ([[http://etherboot.org/share/stefanha/gdbstub.mpg|higher quality version]] 14 MB): |
| [[http://video.google.com/videoplay?docid=-5951365569769661989&hl=en|{{:dev:screencast.png|GDB Remote Debugging for gPXE Screencast}}]] | [[http://video.google.com/videoplay?docid=-5951365569769661989&hl=en|{{:dev:screencast.png|GDB Remote Debugging for gPXE Screencast}}]] | ||
| Line 82: | Line 82: | ||
| **Atomic read/write for device memory**. Memory reads/writes of 2 or 4 bytes are now done atomically. This is important when operating on device memory where a memory operation can have side-effects. Users should do single reads/writes in GDB to deal correctly with device memory, e.g. ''x/w $eax''. Do not attempt to read more than one 2- or 4-byte device register at a time. | **Atomic read/write for device memory**. Memory reads/writes of 2 or 4 bytes are now done atomically. This is important when operating on device memory where a memory operation can have side-effects. Users should do single reads/writes in GDB to deal correctly with device memory, e.g. ''x/w $eax''. Do not attempt to read more than one 2- or 4-byte device register at a time. | ||
| - | Next steps: | + | ==== Fri Jun 6 ==== |
| - | * Send rom-o-matic patch to mdc so that ''GDBSTUB'' can be chosen when configuring a ROM. | + | Had the weekly meeting today and discussed next week's goal: hardware watchpoints and UDP transport. |
| - | * Design a GDB protocol transport interface that serial and UDP can implement. Discuss with mentors. | + | |
| - | * Implement hardware breakpoint and watchpoint support using debug registers. | + | Hardware watchpoints shouldn't require major changes so I want to defer that towards late next week. |
| - | * Using debug register, implement NULL pointer bug guard. | + | |
| + | UDP transport is challenging because we want to support remote debugging over UDP while affecting the network stack as little as possible. The GDB stub is designed to be isolated from the rest of gPXE so that using the debugger does not affect the state of the program. | ||
| + | |||
| + | To send a UDP packet, we'll craft a Ethernet, IP, UDP packet by hand. This side-steps the network stack and reduces dependencies on gPXE functions. Using ''netdev_tx()'' a raw packet can be queued for transmission. | ||
| + | |||
| + | Receiving UDP packets is more difficult. When the GDB stub has control, the program is paused inside an interrupt handler. If we receive a packet not destined for the GDB stub we are in trouble since there is only limited memory available to buffer received packets. | ||
| + | |||
| + | Ideally we could queue up all non-GDB packets so that they are processed when gPXE regains control. But due to finite memory, I am going to implement a strategy that drops all non-GDB packets first. Depending on how that works in practice, I might add something fancier to deal with the memory issue or an eviction policy. | ||
| + | |||
| + | ===== On to week 3 ===== | ||
| + | [[.:week3|Week 3]] | ||
