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 09:42]
stefanha
soc:2008:stefanha:journal:week2 [2008/06/09 03:09] (current)
stefanha
Line 66: Line 66:
  
 ==== Thur Jun 5 ==== ==== Thur Jun 5 ====
-Git commit: [[http://​git.etherboot.org/?​p=people/​stefanha/​gpxe.git;​a=commit;​h=77b559fe736608856b3d5812e6f6fe4c40858732|77b559fe736608856b3d5812e6f6fe4c40858732]]+Git commits: [[http://​git.etherboot.org/?​p=people/​stefanha/​gpxe.git;​a=commit;​h=77b559fe736608856b3d5812e6f6fe4c40858732|77b559fe736608856b3d5812e6f6fe4c40858732]], [[http://​git.etherboot.org/?​p=people/​stefanha/​gpxe.git;​a=commit;​h=f1a3608cbaba4c6777d88aaf3c703c14fc8e8812|f1a3608cbaba4c6777d88aaf3c703c14fc8e8812]]
  
 **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.
  
-Next steps: +**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 time. 
-  ​Send rom-o-matic patch to mdc so that ''​GDBSTUB'' ​can be chosen when configuring a ROM. + 
-  * Design ​GDB protocol ​transport ​interface ​that serial and UDP can implement.  ​Discuss with mentors+==== Fri Jun 6 ==== 
-  ​* Implement hardware breakpoint ​and watchpoint support using debug registers. +Had the weekly meeting today and discussed next week's goal: hardware watchpoints and UDP transport
-  Using debug register, implement NULL pointer bug guard+ 
-  ​* Memory read/write support ​for device ​memory.  ​Check kgdb implementation for rules on device ​memory ​read/write.+Hardware watchpoints shouldn'​t require major changes so I want to defer that towards late next week. 
 + 
 +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]]

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