Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [dsdp-dd-dev] Re: [cdt-dev] Re: New Debug Model

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?


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 :

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.


Spear, Aaron wrote:

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


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


Ken Ryall wrote:

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
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 Piech wrote:
Hi All,
I'll start off by apologizing.  I've been meaning to edit the 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

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.


P.S. I just signed up for dsdp-dd-dev and cdt-dev... better late
then never.

Oberhuber, Martin wrote:

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.

Martin Oberhuber - WindRiver, Austria

-----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
Subject: RE: [cdt-dev] RE: [dsdp-dd-dev] Editor technology


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.


-----Original Message-----
From: 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

I got confused by all the Dougs. :-) I'd like to work with anyone
on  this!


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"

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

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

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


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

some work in this direction. Is there any new information
available on what they are doing?

Mikhail Khodjaiants
----- Original Message ----- From: "Greg Watson"
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


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

of CDT
debugger functionality in the parallel debugger
implementation, it would make sense to try and combine efforts


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.

Doug Schaefer, QNX Software Systems Eclipse CDT Project Lead,
Tools PMC member

-----Original Message-----
From: dsdp-dd-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of Gaff,
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

Toni is currently looking at enhancing the CDT editor and is
collecting some features on the CDT project plan.

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

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

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

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

cdt-dev mailing list
dsdp-dd-dev mailing list
cdt-dev mailing list
dsdp-dd-dev mailing list
dsdp-dd-dev mailing list
cdt-dev mailing list

cdt-dev mailing list

Back to the top