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. Next steps: * Implement hardware watchpoint support using debug registers. * NULL pointer bug guard using watchpoint support. * Use screen captures on [[:dev:gdbstub|GDB stub page]].
