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
