Differences

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

Link to this comparison view

Next revision
Previous revision
soc:2008:stefanha:journal:week2 [2008/06/04 01:05]
stefanha created
soc:2008:stefanha:journal:week2 [2008/06/09 03:09] (current)
stefanha
Line 1: Line 1:
-==== Week 2 ====+====== Stefan Hajnoczi: GDB Remote Debugging ======
  
-=== Mon Jun 2 ===+===== Week 2 ===== 
 + 
 +**Milestone:​** Get GDB stub into mainline. 
 + 
 +==== Mon Jun 2 ====
 Git commit: [[http://​git.etherboot.org/?​p=people/​stefanha/​gpxe.git;​a=commit;​h=0004992b5bb35b4d5df324d8afffae04e3ee8285|0004992b5bb35b4d5df324d8afffae04e3ee8285]] Git commit: [[http://​git.etherboot.org/?​p=people/​stefanha/​gpxe.git;​a=commit;​h=0004992b5bb35b4d5df324d8afffae04e3ee8285|0004992b5bb35b4d5df324d8afffae04e3ee8285]]
  
-**I hit an interesting bug while writing the GDB stub test suite**. ​ The interrupt handler shares the stack with the main thread of control.+**I hit an interesting ​<del>bug</​del>​ thing while writing the GDB stub test suite**. ​ The interrupt handler shares the stack with the main thread of control.  **Update:** hpa informed me that the i386 ABI requires ''​ESP''​ to be top of stack, and therefore this issue cannot happen in conforming code.
  
 If the main thread uses stack memory below the stack pointer when an interrupt comes in, then that memory may be corrupted. ​ The interrupt handler uses the stack to store the CPU state and assumes that memory below the stack pointer is unused. If the main thread uses stack memory below the stack pointer when an interrupt comes in, then that memory may be corrupted. ​ The interrupt handler uses the stack to store the CPU state and assumes that memory below the stack pointer is unused.
Line 28: Line 32:
 </​code>​ </​code>​
  
-=== Tue Jun 3 ===+==== Tue Jun 3 ====
 Git commits: [[http://​git.etherboot.org/?​p=people/​stefanha/​gpxe.git;​a=commit;​h=813fd7500972968b19f17326c5cac308c43b59b6|813fd7500972968b19f17326c5cac308c43b59b6]],​ [[http://​git.etherboot.org/?​p=people/​stefanha/​gpxe.git;​a=commit;​h=6b0bc333ef9123a2f255db49f1346a3cb2d28285|6b0bc333ef9123a2f255db49f1346a3cb2d28285]] Git commits: [[http://​git.etherboot.org/?​p=people/​stefanha/​gpxe.git;​a=commit;​h=813fd7500972968b19f17326c5cac308c43b59b6|813fd7500972968b19f17326c5cac308c43b59b6]],​ [[http://​git.etherboot.org/?​p=people/​stefanha/​gpxe.git;​a=commit;​h=6b0bc333ef9123a2f255db49f1346a3cb2d28285|6b0bc333ef9123a2f255db49f1346a3cb2d28285]]
  
Line 37: Line 41:
 There is currently no check against ''​GDBSTUB''​ and ''​CONSOLE_SERIAL''​ being enabled at the same time.  Just don't do it :-). There is currently no check against ''​GDBSTUB''​ and ''​CONSOLE_SERIAL''​ being enabled at the same time.  Just don't do it :-).
  
-=== Wed Jun 4 === +==== Wed Jun 4 ==== 
-Git commit: [[http://​git.etherboot.org/?​p=people/​stefanha/​gpxe.git;​a=commit;​h=b739cae42af8a7b37def48c9284381e98a91043e|b739cae42af8a7b37def48c9284381e98a91043e]]+Git commit: [[http://​git.etherboot.org/?​p=people/​stefanha/​gpxe.git;​a=commit;​h=b739cae42af8a7b37def48c9284381e98a91043e|b739cae42af8a7b37def48c9284381e98a91043e]], [[http://​git.etherboot.org/?​p=people/​stefanha/​gpxe.git;​a=commit;​h=20a525f3df08af982989663d4c3718af3e985d9b|20a525f3df08af982989663d4c3718af3e985d9b]],​ [[http://​git.etherboot.org/?​p=people/​stefanha/​gpxe.git;​a=commit;​h=2507e1c548bb98f9448e4a343f45c1d55dcef227|2507e1c548bb98f9448e4a343f45c1d55dcef227]],​ [[http://​git.etherboot.org/?​p=people/​stefanha/​gpxe.git;​a=commit;​h=8e93a5edf8e3a91a42c88081c64a255a930f8713|8e93a5edf8e3a91a42c88081c64a255a930f8713]]
  
 **Removed unused ''​arch/​i386/​core/​gdbsym.c''​**. ​ This was an attempt at GDB debugging via QEMU and mcb30 suggested it could be removed. ​ Its ''​GDBSYM''​ ''​config.h''​ option has potential to confuse users wanting to build the GDB stub, so I removed it. **Removed unused ''​arch/​i386/​core/​gdbsym.c''​**. ​ This was an attempt at GDB debugging via QEMU and mcb30 suggested it could be removed. ​ Its ''​GDBSYM''​ ''​config.h''​ option has potential to confuse users wanting to build the GDB stub, so I removed it.
  
-Next steps+**I feel the code is ready for mainline review**. ​ The GDB remote debugging functionality is enabled with ''#​define GDBSTUB''​ in ''​config.h''​. ​ Debugging works over the serial port.  Here's how I test in QEMU
-  * Send rom-o-matic patch to mdc so that ''​GDBSTUB'' ​can be chosen when configuring ​ROM+<​code>​ 
-  Design ​a GDB protocol transport interface ​that serial ​and UDP can implement.  ​Discuss with mentors+$ make # with GDBSTUB enabled in config.h 
-  Handle disconnect properly - ignore ​breakpoints when GDB is not attached+$ make bin/​gpxe.hd.tmp # for debugging symbols 
-  * Implement ​hardware ​breakpoint ​and watchpoint ​support using debug registers+$ qemu -serial tcp::​4444,​server bin/​gpxe.usb 
-  ​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.+[From another terminal] 
 +$ gdb 
 +(gdb) file bin/​gpxe.hd.tmp 
 +(gdb) target remote localhost:​4444 
 +</​code>​ 
 + 
 +To run the test suite, add ''​REQUIRE_OBJECT ( gdbstub_test )'' ​in ''​core/​config.c''​ and rebuild. ​ The gdb invocation works like this: 
 +<​code>​ 
 +$ gdb tests/​gdbstub_test.gdb 
 +</​code>​ 
 + 
 +Once all tests are done, you will be left at the GDB prompt and can type ''​quit''​. 
 + 
 +==== Thur Jun 5 ==== 
 +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. 
 + 
 +Documentation is available [[:​dev:​gdbstub|here]]. ​ I also spent 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}}]] 
 + 
 +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. 
 + 
 +**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
 + 
 +==== Fri Jun 6 ==== 
 +Had the weekly meeting today and discussed next week's goal: hardware ​watchpoints ​and UDP transport. 
 + 
 +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)