This is an old revision of the document!
====== Stefan Hajnoczi: GDB Remote Debugging ====== ===== Week 3 ===== **Milestones:** * GDB remote debugging over UDP. * Hardware watchpoint support for trapping read/write/execute on memory. ==== Mon Jun 9 ==== I had a refreshing weekend with only a little bit of Etherboot hacking on Saturday. The weather was excellent and I was able to recharge batteries a bit :-). The past two weeks of Summer of Code have been an excellent experience. I've had the chance to look behind the scenes of Etherboot and to pitch in and help out. My current focus is on GDB remote debugging over UDP. I think this feature will be very useful since it let's you debug gPXE without using a serial cable. It opens the door to letting developers analyze errors over the internet without having to reproduce them locally from a bug report. I'd really like to see this used in cases where developers do not have hardware on which the error occurs. Today I implemented UDP send and receive without using the network stack. This means hand-crafting Ethernet, IP, UDP packets and parsing them. One detail I hadn't though of is that ARP reply code is also necessary to advertise gPXE's MAC/IP addresses. GDB can already talk to gPXE via UDP. The conversation does not go well though. It deadlocks after a few exchanges and before handshaking is complete when neither side wants to say any more. I think this is either because of bugs in my UDP send/receive code or due to flow control issues when using UDP. The GDB protocol is sensitive to packet ordering. I have tried to implement the GDB protocol in a robust way, so I suspect the error lies in the UDP code. Tomorrow I'll look into this more. Meanwhile, here is a screenshot from [[http://www.wireshark.org/|Wireshark]]: {{:soc:2008:stefanha:journal:udp.png|GDB and gPXE trying to talk to each other over UDP.}} ==== Tue Jun 10 ==== Yesterday's issues were caused by bugs in the UDP send/receive code. UDP debugging now works and passes the test suite. It's fun to watch because the test suite completes so much faster than when using serial. My code for UDP still needs a lot of clean-up and some policy decisions. Here are the open questions: * How to set the network device and IP/port on which to listen? Compile-time option or gPXE shell command? * How to split the serial and UDP transports? Allow both to be compiled in? Choose at runtime or try to use both? I have an idea for avoiding recursion when breakpoints are placed in code used by the GDB stub. Implement hardware/memory breakpoint support in the GDB stub so that we know where breakpoints are set. Upon entering the interrupt handler, temporarily clear all breakpoints. Now all code can be run without fear of recursing into the breakpoint interrupt handler. Upon leaving the interrupt handler, restore all breakpoints. ==== Wed Jun 11 ==== Git commit: [[http://git.etherboot.org/?p=people/stefanha/gpxe.git;a=commit;h=6f668fd80ada1d796c482106139139ada25de663|6f668fd80ada1d796c482106139139ada25de663]] **Committed remote debugging over UDP**. The GDB stub can now be built with serial and/or UDP support. The ''config.h'' options are ''GDBSERIAL'' and ''GDBUDP''. To enter the debugger, execute the gPXE shell command: <code> gdbstub <transport> [<options>...] </code> Where ''<transport>'' is ''serial'' or ''udp''. For ''udp'', the name of a configured network device is required, e.g.: <code> ifopen net0 set net0/ip 192.168.0.2 gdbstub udp net0 </code> The GDB stub listens on UDP port 43770 by default. It was fun to run the test suite against a real machine with a VIA Rhine II NIC booting gPXE from USB. I am interested in feedback about the code. I'm eager to see what reactions it raises and how I can improve it. **In the meantime, hardware watchpoint support will keep me busy**. I got off to a slow start because remote watchpoints are broken in GDB 6.7.1 - 6.8 (at least). Figuring out the bug and how to fix it took a while. I also asked on ''#gdb'' and later found out that the bug is fixed in CVS head. Anyway, this means watchpoints will only work if you run GDB post-6.8. The watchpoint commands are now implemented. The x86 architecture has support for 4 hardware breakpoints. These can either be normal breakpoints or watchpoints. The GDB stub implementation does not support hardware breakpoints in order to keep things simple. I am holding off on a full-blown breakpoint implementation since that may involve implementing memory breakpoints too. Currently GDB manages memory breakpoints and the GDB stub is unaware of them. The original GDB stub code with serial-only support was very minimal. I like concise code. When I added UDP, the code needed to be refactored into more parts. Watchpoints, again, add new functionality. Hopefully we are close to feature-complete, because the GDB stub shouldn't turn into a subsystem of its own. I am going to write tests and polish the code tonight with a commit coming tomorrow. Next steps: * Implement hardware watchpoint support using debug registers. * NULL pointer bug guard using watchpoint support. * Polish UDP code. * Update [[:dev:gdbstub|GDB stub page]] and screencast when UDP code is merged into mainline.
