This is the JNI debug proposal Intel
presented at the CDT Spring Summit, no? It looked very promising and should be
a good stretch of the platform, JDT and CDT debug capabilities. Whatever we do
for debugging in the CDT will need to take this into consideration along with
the needs of device debugging and, of course, existing CDI clients. Could be a
lot of work, but it’ll be pretty cool to bring all these environments
together.
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Gaff, Doug
Sent: Wednesday, May 24, 2006
10:27 AM
To: CDT
General developers list.
Cc: Device
Debugging developer discussions
Subject: RE: [dsdp-dd-dev] Re:
[cdt-dev] Re: New Debug Model
Hi Vitaly,
How far along are you on implementing the mixed language debugger?
Is this going to be released into open source, or is this a commercial
product?
Doug G
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Vitaly Provodin
Sent: Wednesday, May 24, 2006
12:24 AM
To: CDT
General developers list.
Cc: Device
Debugging developer discussions
Subject: Re: [dsdp-dd-dev] Re:
[cdt-dev] Re: New Debug Model
Another
"third party tool": we are working on so called mixed mode debugger
which is intended to debug Java applications with JNI libraries. Our approach
is based on the platform debug model and we try to use the CDT and JDT
functionality as much as possible.
Vitaly
Provodin,
Intel Middleware Products Division
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
|
