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

[Pawel Piech <pawel.piech@xxxxxxxxxxxxx>]

Thank you for the feedback Mario, some comments below:

Mario Pierro wrote:

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.
  

This is a very important point.  Between your and Jesper's comments, I sense that there is a disconnect between the API documentation and what the GDB implementation does.  I would like to address this problem by first adding this documentation to the APIs, and by finding and fixing the places where the APIs are too GDB-centric.  I agree that GDB documentation is also useful, but our long term goal is to try to contribute DSF to platform and there it should be able to stand on its own.

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.
  

The modules VM implementation problem you point out is most likely a bug.  If you file it with some additional details I will try to track it down.  But in general there is a larger issue in that the VM implementations can be difficult to understand.  My best recommendation would be to just file bug where you find the interface confusing (add a [docs] prefix if the problem is missing documentation).  This is the surest way that the feedback from your  learning experience doesn't get lost, because as you get more familiar with the system and its assumptions you're likely to forget these stumbling blocks.

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?
  

Agreed, a standard implementation of frame would be useful.  The reason that the level turns out to be important for equals is that there is a lot of optimization logic in place to make UI refreshes when stepping efficient.

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.
  

I agree here also.  Once again, with the goal of a generic framework in mind, I would like to have as few dependencies on CDT as possible.  The source lookup implementation in GDB was never properly refactored to separate it into CDT and non-CDT parts.  If there isn't a bug for this already, we should file one.

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.
  

Yes, this is an old bug which we just haven't gotten to yet.

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.
  

It has more to do with the caching mechanism in the view model.  There is another large refactoring to be done in the view model, which would allow us to stop using the deprecated IDMService.getModelData(), and then to simplify the formatted data API and some other details in the services interfaces.  I was hoping that we could do this in the 1.1 time frame, but unfortunately we didn't have enough recources for it.

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? 
  

I don't really understand the problems of the memory service and we definitely use some outside expertise on it.  In fact I was wondering recently whether we really need to use the IAddress interface to represent addresses.  From your comment it seems that using IAddress is important, so I would like to know more about how you would like to see the related APIs evolve.

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?
  

Developing a test framework was one of my major goals last summer.  For this end I implemented a view-less flexible hierarchy viewer which I plan to use to write generic View Model implementation tests.  These tests could be re-used to validate different view model implementations and back ends.  But I'm afraid that at this point the test viewer still exists only as a patch in platform and I have not gotten to writing any view model tests.  Right now we are in feature development cycle for 3.5, so I'm not likely to get back to this one for quite a while.

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

  

Thank you for trying DSF and I hope to keep working with you to improve it.

Cheers,
Pawel