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:journal:week2 [2008/06/05 12:08]
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}}]]
  
 I hope others find it helpful to add GDB to the (small) set of gPXE debugging tools. I hope others find it helpful to add GDB to the (small) set of gPXE debugging tools.
 +
 +**Please note that changes and git commits described from here onward may not be in mainline gPXE**. ​ When something gets merged, I will make a note of it.
  
 **Detach and kill are now handled**. ​ In the new ''​gdbstub2''​ branch, I've added code to leave the GDB stub when GDB detaches or asks to "​kill"​ it.  It might be a good idea to manually clear all breakpoints before detaching. ​ The GDB stub does not keep track of breakpoints and therefore has no way to automatically clear them when GDB disconnects. **Detach and kill are now handled**. ​ In the new ''​gdbstub2''​ branch, I've added code to leave the GDB stub when GDB detaches or asks to "​kill"​ it.  It might be a good idea to manually clear all breakpoints before detaching. ​ The GDB stub does not keep track of breakpoints and therefore has no way to automatically clear them when GDB disconnects.
Line 80: 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 goalhardware 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 ​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]]

QR Code
QR Code soc:2008:stefanha:journal:week2 (generated for current page)