Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [dsdp-dd-dev] debug model requirements discussion 
Hi Mikhail,
(my comments inlined)

Mikhail Khodjaiants wrote:

Pawel,


As far as your second question, do you feel that the requirements listed
are too broad and/or too ambitious?


For me the definition of "a debug model" (not "the debug model") in this
context is an abstraction in form of API that describes a family of debugger
engines. Combined with the implementation that adapts the model into the
Eclipse debug platform it will allow clients to integrate backend debuggers
into Eclipse.
That's a very nice, concise and eloquent definition :-) 
The obvious example of a debug model is the platform debug model, which
works very well for Java debuggers, but doesn't work for embedded purposes.
As you know it used to be the only debug model supported by Eclipse. Now
it's one of the possible backend models.
So, IMO we shouldn't try to come up with a universal API and make the UI
components heavily depend on it. Instead we should focus on the design of
the UI component that can work with various models. Current platform views
are good examples of what we need.
I absolutely agree with you on the point that writing the debug model API to match the desired UI representation turned out to be a mistake. I see two main problems with it: 1) with different debuggers, someone will want a different UI representation, 2) it doesn't allow the debugger implementation to be modular (at least not without having an adapter layer for the APIs).
To address problem #1, we now have flexible hierarchy views, which by itself is a good mechanism for making small changes on top of the existing Platform model layout. But for large extensions, flexible hierarchy leaves the model design completely up to the implementor, which is good, but it leaves the implementor with a pretty large burden. Also using flexible hierarchy, doesn't provide a standard API of accessing this data for purposes other than populating views. As far as problem #2, I think at this point it's a completely open question. 
I have never been a fan of Chairman Mao, but I would like to quote him here:
"Let a hundred flowers bloom." :). I believe this expression describes the
whole Eclipse ideology very well.
These are just general thoughts on the role of a debug model in Eclipse.
Regarding the requirements, my question is how to interpret the following:
Even though many aspects of embedded debugging is unique to a given
vendor/target configuration, etc, all of these debuggers share some common
functionality found in standard debuggers (reading/writing memory, run
control, stack retrieval, expression evaluation, etc).

  a.. Debug model should define a set of public APIs to access common
debugger functionality, either by supporting existing APIs (Platform, CDI,
JDI) or defining new ones.
  b.. If new APIs are defined, the model should have the ability to support
legacy APIs: Platform, CDI, etc.
Is this is supposed to be a universal API that will replace the platform
debug model, it is too ambitious. As you know, the first attempt failed and
there is no guarantee that another attempt will not fail again.
If it is not a proposal for a universal API then it is confusing and needs a
clarification. I don't think Darrin is planning to abandon the platform API
in JDT, neither the CDT team has plans to drop CDI. Moreover, we are
considering to improve it and take advantage of the new implementation of
the debug views.
I guess to answer the key question: I do believe there is a place for a "universal" API for debuggers. But I don't think it can be a fixed set of interfaces that will satisfy all debugger implementors for all time. Instead I think the problem can be addressed by creating a framework where modules are assembled together to form a complete implementation of a debugger. Some modules can implement published APIs for most standard debugger functionality like what the platform debug model covers. Other modules can implement more specialized APIs, dealing with technology-specific capabilities, while still other modules could be completely vendor-specific and proprietary. Of course this is not to say that you can't have a monolithic implementation of a debugger, but at least you shouldn't be forced into it by the API design.
I really don't know if CDI or platform debug model could be morphed to meet such a design goal. I have to admit though that I am rather skeptical, because these APIs were designed with a specific UI representation in mind and this is what forced mixing together all the parts of the debugger which otherwise could potentially be made modular. This doesn't mean that CDI or platform debug model should or could be "abandoned". They work well in many if not most situations, and there is a lot of client code as well as debugger implementations that are written against them. That's why I said that if these models cannot be made to meet the stated requirements, the new universal model that is to be invented needs to support them at least through a compatibility layer. 

Cheers
Pawel


Regards,
Mikhail
----- Original Message ----- From: "Pawel Piech" <pawel.piech@xxxxxxxxxxxxx> 
To: "Device Debugging developer discussions" <dsdp-dd-dev@xxxxxxxxxxx>
Sent: Thursday, June 08, 2006 7:56 PM
Subject: Re: [dsdp-dd-dev] debug model requirements discussion



Thank you Mikhail,
Good point.  I guess I assumed that "Debug Model" implies the objective
of a discussion, but it obviously doesn't.  I added an objective stated as

    To define a set of APIs and a mechanism for extending these APIs to
    allow various debugger implementations to:

       1. drive content of debug views,
       2. allow users to perform operations to change the state of the
          debugger,
       3. allow 3rd party tools and standard clients to interact with
          debugger.

As far as your second question, do you feel that the requirements listed
are too broad and/or too ambitious?

Cheers
Pawel

Mikhail Khodjaiants wrote:

Hi Pawel,

I've had a quick look at the requirements and I think the objective
part is missing.
Reading the requirements one can get the impression that you are
proposing to come up with a universal API and implement debug views
and other UI components on the top of it. Is this correct or not?
In any cases, the goal should be identified from the beginning.

Thanks,
Mikhail Khodjaiants

----- Original Message ----- From: "Pawel Piech"
<pawel.piech@xxxxxxxxxxxxx>
To: "Device Debugging developer discussions" <dsdp-dd-dev@xxxxxxxxxxx>
Sent: Thursday, June 08, 2006 2:18 PM
Subject: [dsdp-dd-dev] debug model requirements discussion



Hi all,
Based on the information I gathered so far, I listed the DSDP
requirements for a debug model on the twiki page:
http://wiki.eclipse.org/index.php/DSDP/DD/DebugModel

I gave up on the hypothetical debugger example, or on trying to collect
all the use cases to support all the requirements.  Given how in this
group everyone seems to rather familiar with the problem space, it

might

be easier to just come up with use cases as needed to justify specific
requirements.
-Pawel

_______________________________________________
dsdp-dd-dev mailing list
dsdp-dd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev

_______________________________________________
dsdp-dd-dev mailing list
dsdp-dd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev

_______________________________________________
dsdp-dd-dev mailing list
dsdp-dd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev


_______________________________________________
dsdp-dd-dev mailing list
dsdp-dd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev

Back to the top