| Re: [dsdp-dd-dev] Some thoughts on DSF |
Hi Jesper,Thank you for the feedback and for giving DSF a try. Before going into the specific issues I should say that DSF is still a young framework and we have a lot of opportunity to make adjustments... even backward compatibility breaking changes if there's a clear benefit to it. So I really hope that you and anyone else trying DSF can take a little time and keep letting us know what are the biggest pain points are and what to do to address them.
Jesper Eskilson wrote:
Choosing GDB was the logical choice for creating a user community for the framework. Also many vendors including Wind River have debugger engines which use the MI protocol without necessarily being based on GDB. But I agree completely that this leaves us vulnerable to being too GDB specific. There is another open source DSF implementation: using TCF protocol from the DSDP/TM project. But that implementation is still in prototype stages and needs major work before being production ready.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).I'd be very interested in what those cases are. It may be that there are bugs in the framework, or that the design has some bad assumptions, or that the APIs simply need to be better documented. There are a lot of rather subtle requirements in DSF that have to do with concurrency, and they seems to be a major stumbling block for new developers.
I have to complete agree here as well. Part of the problem here is that debugging asynchronous frameworks is inherently difficult (debugging the flexible hierarchy viewer implementation in platform is just as tricky). When writing the concurrency objects for the framework I tried to include some tools to help debugging. For example you can turn on tracing of all the runnables that are handled by the executor (using org.eclipse.dd.dsf/debug/executor option), which will also print a message whenever a RequestMonitor is garbage collected without ever being completed. But I didn't find this tool particularly useful for debugging real problems, so I haven't advertised it much. There are also annoying pitfalls such as bug 236915, which make debugging more difficult still. So as the framework becomes more mature and we get more users, I really hope that new ideas will surface on how to improve this situation. For now, I kind of feel like we're stuck with doing a lot of guess work when debugging the system. The good news is that experience helps a lot here. Learning how to overall system works makes it easier to know where the common failure points are.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.I am very happy to hear that you are making progress with DSF, and I'm glad to answer any questions and provide guidance. Our decision to create an alternative to the standard debug model was very ambitious (if not arrogant), so any positive real world feedback is extremely encouraging. I realize though that we still have a long way to go...
Cheers, Pawel