On 5/23/06, Pawel Piech <
pawel.piech@xxxxxxxxxxxxx> wrote:
Hi Adam,
This is very useful information. Could you clarify though, do you write
views and UI code that interacts with other vendor's debuggers as well?
Thanks
Pawel
Adam Finucane wrote:
> Hello Pawel,
>
> Just letting you known that there are some third party tools that use the CDT
> debugger APIs, namely us.
>
> We use the existing CDI debugger framework to provide simulators and hardware
> debuggers for some embedded microprocessors. The simulator is pure Java, the
> in circuit debugger is a mix of Java and JNI, we don't use GDB.
>
> We have our own low level framework from which we implement specific debuggers
> for each chip we want to support. We provide the common glue between the CDI
> interfaces and our own low level interfaces.
>
> We haven't gone into complex breakpoints yet, I can see that this could be a
> problem if we do try to implement them, but generally speaking we have the
> interface to be good so far. Some small issues have popped up, basically
> memory spaces not being supported but I understand that this is being
> implemented in the next release of CDT, and it wasn't difficult to work
> around. The other issue that popped up is, because we didn't use GDB, we had
> to implement our own _expression_ parser. We implemented a bare bones
> '_expression_ parser' that simple parses literals, but it would be nice if
> there was a framework all ready in place and all that would have to be done
> would be to provide the sizes of types and symbol lookups.
>
> Adam Finucane
>
> HI-TECH Software
> E-mail: adam@xxxxxxxxxx
> Web :
www.htsoft.com
>
>
> On Saturday 20 May 2006 07:53, Pawel Piech wrote:
>
>> Hi Aaron,
>> I understand what you're getting at. Both the platform debug model and
>> CDT (and JDT) provide a set of standard interfaces for the various types
>> of objects in a given debugger implementation. So I would love to know
>> how many third party tools are there that take advantage of these APIs
>> and with what level of success. Also, assuming that there are some such
>> tools out there, does it mean that whatever new debug model we come up
>> with, will it have to be compatible with these legacy debug models?
>>
>> In our experience, we get sporadic requests for APIs to integrate third
>> party tools with, and in some cases the platform debug model is
>> sufficient, but in some cases it is not... especially with respect to
>> breakpoints. This is fine, it can be argued that if we implemented the
>> CDI interfaces, we would have a higher-level of compatibility with 3rd
>> party tools because it provides more functionality. But it seems that
>> there is always going to be some custom functionality in embedded
>> debuggers (for example specific types of hardware breakpoints), that are
>> not going to be covered by any standard API. Plus having these
>> expansive sets of interfaces can be rather expensive to design,
>> implement, and maintain. Meanwhile, it's so hard to tell what
>> functionality a 3rd party vendor would actually use.
>>
>> So I'm wondering whether there are more specific use cases that people
>> know of which would help us come up with alternatives to this standard
>> hierarchical interface approach. An example of this might be for each
>> debugger implementation to expose sets of commands (such as resetting,
>> downloading, setting breakpoints, etc.) that can be applied on the
>> different objects belonging to that debugger, then have some limited
>> framework that would let users and tool vendors use these commands in
>> scripts or some other configurable mechanisms.
>>
>> -Pawel
>>
>> Spear, Aaron wrote:
>>
>>> Pawel,
>>>
>>> I will take a stab at what I think Ken is getting at: I would think the
>>> use case would be any other vendor that wanted to build something on top
>>> of a debugger and have it work with multiple debuggers. So in theory
>>> they write their tool and then can run it on top of anyones embedded
>>> debugger (CDT or WorkBench or EDGE or ...). Say for example an RTOS
>>> vendor that wanted to write kernel awareness of some kind that listened
>>> for events and then iterated global variables displaying their data
>>> structures on a target stop. Another example would be semiconductor
>>> vendors who want to add views and such that are specific to features of
>>> their chips and have it run on multiple debuggers. We are asked about
>>> this all the time. More than once I have heard "We can just write an
>>> Eclipse plugin right?" Sure provided the framework is there...
>>>
>>> cheers,
>>> Aaron
>>>
>>> -----Original Message-----
>>> From: dsdp-dd-dev-bounces@xxxxxxxxxxx
>>> [mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of Pawel Piech
>>> Sent: Wednesday, May 17, 2006 4:44 PM
>>> To: CDT General developers list.
>>> Cc: Device Debugging developer discussions
>>> Subject: Re: [dsdp-dd-dev] Re: [cdt-dev] Re: New Debug Model
>>>
>>> Hi Ken,
>>> I totally agree with everything you're saying, it's just a really tough
>>> challenge: to design a standard debug model implementation in
>>> components, such that they can be selectively replaced to provide custom
>>> functionality... a very worthy goal though.
>>>
>>> Still what I'm struggling with right now is the question of "other
>>> tools" and interoperability between models. What are the specific
>>> use-cases for other tools accessing the debug model? And what features
>>> require debug models to collaborate with each other?
>>>
>>> Thanks
>>> Pawel
>>>
>>> Ken Ryall wrote:
>>>
>>>> Pawel,
>>>>
>>>> For now just a couple thoughts:
>>>>
>>>> The new platform model is wonderfully flexible but a model for C/C++
>>>> debuggers needs to provide enough common structure to make it reusable
>>>>
>>>>
>>>>
>>>> across back-ends. Otherwise there is not much to leverage and other
>>>> tools don't have a way to address debugger stuff. The more common
>>>> elements we can put into the model, the more we can collaborate.
>>>>
>>>> A debug model for C/C++ should as much as possible allow the back-end
>>>> to provide as rich a debug experience as it can. That's not to say
>>>> that the model has to let every back-end interact exactly the way it
>>>> wants to, some glue and various adjustments will usually be necessary.
>>>>
>>>> A debug model should address the most common debugger use cases and
>>>> let back-ends opt out and do their own thing when they do something
>>>> wildly different. But in those cases the benefits of the model should
>>>> also provide an incentive for people to adjust their debugger
>>>> back-ends to better match the model.
>>>>
>>>> Looking forward to a more in-depth discussion later on.
>>>>
>>>> Thanks - Ken
>>>>
>>>>
>>>>> From: ext Pawel Piech <
pawel.piech@xxxxxxxxxxxxx>
>>>>> Reply-To: Device Debugging developer discussions
>>>>> <
dsdp-dd-dev@xxxxxxxxxxx>
>>>>> Date: Tue, 16 May 2006 17:03:29 -0700
>>>>> To: "CDT General developers list." <
cdt-dev@xxxxxxxxxxx>
>>>>> Cc: Device Debugging developer discussions < dsdp-dd-dev@xxxxxxxxxxx
>
>>>>> Subject: [dsdp-dd-dev] Re: [cdt-dev] Re: New Debug Model (was: Editor
>>>>>
>>>>>
>>>>>
>>>>> technology subgroup)
>>>>>
>>>>> As promised, I started on defining the requirements for an optimal
>>>>> debug model design for embedded debugging. I took kind of a fun
>>>>> approach to the problem, so please let me know if you think it's
>>>>> confusing or inappropriate.
>>>>> -Pawel
>>>>>
>>>>> See:
http://wiki.eclipse.org/index.php/DSDP/DD/DebugModel
>>>>>
>>>>> Pawel Piech wrote:
>>>>>
>>>>>> Hi All,
>>>>>> I'll start off by apologizing. I've been meaning to edit the
>>>>>> http://wiki.eclipse.org/index.php/DSDP/DD/DebugModel to start
>>>>>> collecting requirements, but it seems like such a daunting task that
>>>>>>
>>>>>>
>>>>>>
>>>>>> I ended up putting it off week after week :-( So rather than make
>>>>>> up more excuses I'll make sure that I get started on it today. If
>>>>>> anyone already has a set of requirements written up, please feel
>>>>>> free to post them on the twiki page or mail them to the list, it'll
>>>>>> make this process a lot easier.
>>>>>>
>>>>>> Separately, we have been working on a prototype that we will commit
>>>>>> to CVS shortly. This is the same prototype that we talked about in
>>>>>> the February DSDP meeting, except we have rewritten it a couple of
>>>>>> time since to take advantage of standards that are in JDK 5.0 and in
>>>>>>
>>> OSGI.
>>>
>>>
>>>>>> At this point, aside from javadocs and example code, the prototype
>>>>>> code is ready to commit, we're just waiting to get the required
>>>>>> signatures from within the company. So rather than try to describe
>>>>>> what this thing is about, I'd rather wait another week or so and
>>>>>> just post the code for everyone to look at.
>>>>>>
>>>>>> -Pawel
>>>>>>
>>>>>> P.S. I just signed up for dsdp-dd-dev and cdt-dev... better late
>>>>>> then never.
>>>>>>
>>>>>> Oberhuber, Martin wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> while Doug Gaff is at the WR User Conference in Orlando, let me go
>>>>>>> ahead and start the new thread :-)
>>>>>>>
>>>>>>> Yes, Pawel P has made quite some progress on prototyping against
>>>>>>> the Flexible Debug Model. Sine quite a bit of this is based on
>>>>>>> former WR proprietary code, we'll need to wait for IP clearance
>>>>>>> before we can actually make a contribution.
>>>>>>>
>>>>>>> We hope this to happen anytime soon.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Martin
>>>>>>> --
>>>>>>> Martin Oberhuber - WindRiver, Austria
>>>>>>> +43(662)457915-85
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From:
dsdp-dd-dev-bounces@xxxxxxxxxxx
>>>>>>>> [mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx
] On Behalf Of Ewa Matejska
>>>>>>>> Sent: Friday, May 12, 2006 8:43 PM
>>>>>>>> To: CDT General developers list.; Device Debugging developer
>>>>>>>> discussions
>>>>>>>> Subject: RE: [cdt-dev] RE: [dsdp-dd-dev] Editor technology
>>>>>>>> subgroup
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I propose starting a new thread for future communications about
>>>>>>>> the Debug Model since there's a technology subgroup in the
>>>>>>>> DSDP-DD. I would like to leave this thread for Editor
>>>>>>>> enhancement/ideas/requests focusing on embedded development.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Ewa.
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From:
cdt-dev-bounces@xxxxxxxxxxx
>>>>>>>> [mailto:
cdt-dev-bounces@xxxxxxxxxxx ]
>>>>>>>> On Behalf Of Greg Watson
>>>>>>>> Sent: Friday, May 12, 2006 10:45 AM
>>>>>>>> To: CDT General developers list.
>>>>>>>> Subject: Re: [cdt-dev] RE: [dsdp-dd-dev] Editor technology
>>>>>>>> subgroup
>>>>>>>>
>>>>>>>> I got confused by all the Dougs. :-) I'd like to work with anyone
>>>>>>>> on this!
>>>>>>>>
>>>>>>>> Greg
>>>>>>>>
>>>>>>>> On May 12, 2006, at 9:48 AM, Mikhail Khodjaiants wrote:
>>>>>>>>
>>>>>>>>> Doug S,
>>>>>>>>>
>>>>>>>>> I sent my previous message before I saw yours. It is for Doug G
>>>>>>>>>
>>>>>>>>> Mikhail K
>>>>>>>>> ----- Original Message ----- From: "Doug Schaefer"
>>>>>>>>>
>>>>>>>> < DSchaefer@xxxxxxx>
>>>>>>>>
>>>>>>>>
>>>>>>>>> To: "CDT General developers list." < cdt-dev@xxxxxxxxxxx
>
>>>>>>>>> Sent: Friday, May 12, 2006 11:46 AM
>>>>>>>>> Subject: RE: [cdt-dev] RE: [dsdp-dd-dev] Editor technology
>>>>>>>>> subgroup
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Which Doug is everyone talking about :).
>>>>>>>>>>
>>>>>>>>>> Since the Greg's note was sent to cdt-dev, I thought it was for
>>>>>>>>>> me. This note sounds like it is for Doug G...
>>>>>>>>>>
>>>>>>>>>> Doug Schaefer, QNX Software Systems Eclipse CDT Project Lead,
>>>>>>>>>> Tools PMC member http://cdtdoug.blogspot.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-
>>>>>>>>>>
bounces@xxxxxxxxxxx] On Behalf Of Mikhail Khodjaiants
>>>>>>>>>> Sent: Friday, May 12, 2006 11:35 AM
>>>>>>>>>> To: CDT General developers list.
>>>>>>>>>> Subject: Re: [cdt-dev] RE: [dsdp-dd-dev] Editor technology
>>>>>>>>>> subgroup
>>>>>>>>>>
>>>>>>>>>> Doug,
>>>>>>>>>>
>>>>>>>>>> There was a special group formed among others at the last DSDP
>>>>>>>>>> meeting to work on the design of the debug model. I volunteered
>>>>>>>>>> to participate, but I haven't heard anything since. You
>>>>>>>>>> mentioned that Pavel and
>>>>>>>>>>
>>>>>>>> Ted are
>>>>>>>>
>>>>>>>>
>>>>>>>>>> doing
>>>>>>>>>> some work in this direction. Is there any new information
>>>>>>>>>> available on what they are doing?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Mikhail Khodjaiants
>>>>>>>>>> ----- Original Message ----- From: "Greg Watson"
>>>>>>>>>> <
g.watson@xxxxxxxxxxxx>
>>>>>>>>>> To: "CDT General developers list." <
cdt-dev@xxxxxxxxxxx>
>>>>>>>>>> Sent: Friday, May 12, 2006 11:11 AM
>>>>>>>>>> Subject: Re: [cdt-dev] RE: [dsdp-dd-dev] Editor technology
>>>>>>>>>> subgroup
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Doug,
>>>>>>>>>>>
>>>>>>>>>>> I wonder if we could be involved in the design of the next
>>>>>>>>>>> generation debugger model? We're also looking at how to use the
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> flexible debug model
>>>>>>>>>>> for the parallel debugger. Since we reused
>>>>>>>>>>> considerable
>>>>>>>>>>>
>>>>>>>> portions
>>>>>>>>
>>>>>>>>
>>>>>>>>>>> of CDT
>>>>>>>>>>> debugger functionality in the parallel debugger
>>>>>>>>>>> implementation, it would make sense to try and combine efforts
>>>>>>>>>>> here.
>>>>>>>>>>>
>>>>>>>>>>> Greg
>>>>>>>>>>>
>>>>>>>>>>> On May 12, 2006, at 8:19 AM, Doug Schaefer wrote:
>>>>>>>>>>>
>>>>>>>>>>>> BTW, Welcome Toni!
>>>>>>>>>>>>
>>>>>>>>>>>> We've been in need of some focus on the CDT editor for a while
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> and I look forward to your contributions.
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Doug Schaefer, QNX Software Systems Eclipse CDT Project Lead,
>>>>>>>>>>>> Tools PMC member http://cdtdoug.blogspot.com
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From:
dsdp-dd-dev-bounces@xxxxxxxxxxx
>>>>>>>>>>>> [mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx
] On Behalf Of Gaff,
>>>>>>>>>>>> Doug
>>>>>>>>>>>> Sent: Wednesday, May 10, 2006 2:43 PM
>>>>>>>>>>>> To: Device Debugging developer discussions
>>>>>>>>>>>> Cc: Leherbauer, Anton; CDT General developers list.
>>>>>>>>>>>> Subject: RE: [dsdp-dd-dev] Editor technology subgroup
>>>>>>>>>>>>
>>>>>>>>>>>> Hi folks,
>>>>>>>>>>>>
>>>>>>>>>>>> I've asked Toni Leherbauer from my team to provide input
>>>>>>>>>>>>
>>>>>>>> on the
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>> editor.
>>>>>>>>>>>> Toni is currently looking at enhancing the CDT editor and is
>>>>>>>>>>>> collecting some features on the CDT project plan.
>>>>>>>>>>>>
http://wiki.eclipse.org/index.php/CDT/planning/4.0
>>>>>>>>>>>>
>>>>>>>>>>>> Since there is interest in the editor in both the CDT and DD
>>>>>>>>>>>> projects, we should keep both groups in the loop. And of
>>>>>>>>>>>> course, we should have one editor solution in the end (in
>>>>>>>>>>>> CDT). We started
>>>>>>>>>>>>
>>>>>>>> discussing
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>> this in
>>>>>>>>>>>> the DD project in Toronto simply as a way to capture
>>>>>>>>>>>> requirements as they related to debugging.
>>>>>>>>>>>>
>>>>>>>>>>>> Also, as I mentioned on the recent DD call, Ted and Pawel are
>>>>>>>>>>>> working on a prototype for a generic debugger implementation
>>>>>>>>>>>> of the
>>>>>>>>>>>>
>>>>>>>> Eclipse
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>> 3.2
>>>>>>>>>>>> debug model interfaces (EDMI
3.2 for short). The goal
>>>>>>>>>>>>
>>>>>>>> is that this
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>> prototype will form the basis of a next-generation debugger
>>>>>>>>>>>> model that benefits folks using CDT and folks working directly
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> with the Eclipse platform today. We intend to get this
>>>>>>>>>>>> committed in the
>>>>>>>>>>>>
>>>>>>>> next few
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>> weeks
>>>>>>>>>>>> so that the community can start discussing architecture,
>>>>>>>>>>>> interfaces, and requirements.
>>>>>>>>>>>>
>>>>>>>>>>>> So regarding the editor, I see open questions around how we
>>>>>>>>>>>> integrate disassembly, breakpoints, instruction pointers, etc.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> with a new debugger implementation. I am also wondering how
>>>>>>>>>>>> the editor will
>>>>>>>>>>>>
>>>>>>>> deal with
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>> multiple debug engines simultaneously (for example, how
>>>>>>>>>>>>
>>>>>>>> to set the
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>> default breakpoint scope).
>>>>>>>>>>>>
>>>>>>>>>>>> Doug
>>>>>>>>>>>>
>>>>>> _______________________________________________
>>>>>> cdt-dev mailing list
>>>>>>
cdt-dev@xxxxxxxxxxx
>>>>>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>>>>>>
>>>>> _______________________________________________
>>>>> dsdp-dd-dev mailing list
>>>>>
dsdp-dd-dev@xxxxxxxxxxx
>>>>> https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
>>>>>
>>>> _______________________________________________
>>>> cdt-dev mailing list
>>>>
cdt-dev@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/cdt-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
>>>
>> _______________________________________________
>> cdt-dev mailing list
>>
cdt-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>>
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev