| [dsdp-dd-dev] Some thoughts on DSF |
We've been working on implementing a DSF debugger model for our debugger for the last couple of months, and a few things stand out in the "not so good" column (there are lots of things in the "very good" column, so don't take me wrong here):
1. Having GDB as the only (semi-)official reference implementation kind of defies the purpose of designing a debugger-API which caters well towards embedded debuggers. One of the main issues of CDI is that it is (very) GDB-biased, so if DSF is supposed to *not* be GDB-biased, using GDB as a reference implementation is a little risky.
2. We've several times been in the situation that unless we implement things *exactly* as the GDB reference implementation, things don't work. Maybe this is a side-effect of DSF being very flexible (perhaps too flexible?), and that different ways of implementing things haven't been properly tested (which is kind of what we are doing now, I guess).
3. Debugging is hopelessly difficult. Debugging is under best circumstances difficult, but following the control flow in DSF is in many cases impossible. The fragile behavior of request monitors is especially annoying; if you miss a call to done() somewhere you won't get an error, things will just stop or hang.
As I said, there a lots of things in the "very good" column. The fact that we have gotten this far (run-control, source-lookup, variables, expressions, memory-view, etc.) in just a couple of months is impressing people around here.
-- /Jesper