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