[dsdp-dd-dev] Re: Some thoughts on DSF

["Mario Pierro" <Mario.Pierro@xxxxxxx>]

Hello Pawel,

>> 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...

I have been working now for some months together with Jesper on a prototype implementation of our debugger that uses DSF. Being new to the API, I started off by reading the DSF tutorials and then going through the code of the GDB reference implementation. 

I have been following your conversation with Jesper and I would like to report some difficulties encountered during the development of our prototype. Please note that I have started working with DSF only recently, so some of those points might well be my own misunderstandings of how the API works. Also, I must say that even if those issues shown up, DSF has proven to be a very powerful API. The service-based approach has made fairly easy for us to lay out a project for interfacing our debugger to Eclipse, and to keep the project on track obtaining a functional prototype in just a few months of work.

We are currently working against the 1.0 maintenance branch of DSF, which is what the following observations refer to. We tried switching to 1.1 but that apparently broke some functionality (e.g. stack frames display). We plan to address the 1.1 compatibility issues when the final 1.1 is released. Is a changelog between 1.0 and 1.1 available?

1) The major shortcoming of DSF that we encountered during our testing is the lack of documentation, as there are some points in the framework where is not clear what the API contract is (see the following points for some examples). The tutorials are good, but a full documentation for the GDB reference implementation would be better, even just for the general project structure without involving the MI protocol details.

2) View model: it is not always clear which data format do view models expect (e.g., are null values allowed? What should the ancestors of a specific DMContext be?). Also, even if it is usually the responsibility of the service to call done() on data request monitors, we have a case in the IModules service implementation where this causes an IllegalStateException if done() is called, and stalls the update if it isn't.

3) Definition of equals() of stack frame Data Model Contexts:It turned out that if we didn't define equality/hashing of stack frames as in the GDB implementation (by means of "level" comparison) the expression data caching would not work, always fetching data from the backend. Maybe a candidate for an AbstractFrameDMContext class? How accurate should the Frame context definition be?

4) In addition to the API classes for source lookup, the GDB source lookup service is actually usable as it is, but it maybe needs to be moved to API separating the GDB specific parts from the general file-based source lookup. Specifically, the GDB (org.eclipse.dd.mi.service.CSourceLookup) service implementation relies on the standard CDT's CSourceLookupDirector to perform its work, so that its only GDB-specific part is the translation of Eclipse source container paths to GDB source locations (setSourceLookupPath, etc...). By cutting that off, the service can be used without any GDB dependency left. Also, while the source lookup is described in the PDA tutorial, the API classes used by GDB are not documented.

5) Also in source lookup: when a file is not found (i.e. when a null filename is reported by the backend) a new "unknown" tab is displayed every time. Such behavior is defined in the private method DsfSourceDisplayAdapter.performLookup() method (DsfSourceDisplayAdapter.java: line 135). Would it maybe be better to make the source display customizable? Having the lookup jobs infrastructure in place saves a lot of work, so being able to override only some parts of the behavior would be great.

6) As with handling formatted values: I wonder if the separation between an expression's data and its format is something related to how GDB must approach the problem. In our case, that means fetching the same data from the backend twice, once for type description and then for actual value retrieval - since the type description must be expressed in the Data, while the format is only known when the FormattedValueContext is supplied.

7) Memory addressing: are there any plans for DSF to incorporate an extension to the IAddress interface, in order to be able to see different memory zones with different characteristics? 

8) Tests: we are now testing our backend classes, without involving DSF. We are going to lay out tests for the DSF services this week. Do you know if it is possible to run those tests in "headless" mode? (that is, without any GUI dependency involved). Also, it seems that there are no "DSF compliance" tests, e.g. view model-based, to check that the services actually perform what the API is expecting from them. I have noticed a bug filed for this ( 217895 , 159680 ), should that include the possibility of connecting to an arbitrary backend to test its compliance?


Again, I must say that even if still young, DSF has a lot of potential and it has really helped us in our work.

Best,

Mario