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 Vitaly,
Yes, I would also love to know more about your progress and which approach number you are leaning toward, because I actually think there is a lot of overlap in what we are trying to accomplish. Thanks
Pawel

Vitaly Provodin wrote:
Hello Pavel,
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. Here is the foils describing our visions: http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/cdt-home/presentations/spring2006/debugger_for_eclipse.ppt?cvsroot=Tools_Project <http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/cdt-home/presentations/spring2006/debugger_for_eclipse.ppt?cvsroot=Tools_Project> Vitaly Provodin,
Intel Middleware Products Division


On 5/23/06, *Pawel Piech* <pawel.piech@xxxxxxxxxxxxx <mailto: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 <mailto:adam@xxxxxxxxxx>
    > Web   : www.htsoft.com <http://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>
    >>> [mailto: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
    <mailto:pawel.piech@xxxxxxxxxxxxx>>
    >>>>> Reply-To: Device Debugging developer discussions
    >>>>> <dsdp-dd-dev@xxxxxxxxxxx <mailto:dsdp-dd-dev@xxxxxxxxxxx>>
    >>>>> Date: Tue, 16 May 2006 17:03:29 -0700
    >>>>> To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx
    <mailto:cdt-dev@xxxxxxxxxxx>>
    >>>>> Cc: Device Debugging developer discussions <
    dsdp-dd-dev@xxxxxxxxxxx <mailto: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
    <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>
    >>>>>>>> [mailto: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>
    >>>>>>>> [mailto: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 <mailto:DSchaefer@xxxxxxx>>
    >>>>>>>>
    >>>>>>>>
    >>>>>>>>> To: "CDT General developers list." < cdt-dev@xxxxxxxxxxx
    <mailto: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
    <http://cdtdoug.blogspot.com>
    >>>>>>>>>>
    >>>>>>>>>>
    >>>>>>>>>> -----Original Message-----
    >>>>>>>>>> From: cdt-dev-bounces@xxxxxxxxxxx
    <mailto:cdt-dev-bounces@xxxxxxxxxxx> [mailto:cdt-dev-
    <mailto:cdt-dev->
    >>>>>>>>>> bounces@xxxxxxxxxxx <mailto: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 <mailto:g.watson@xxxxxxxxxxxx>>
    >>>>>>>>>> To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx
    <mailto: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>
    >>>>>>>>>>>> [mailto: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
    <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 <mailto:cdt-dev@xxxxxxxxxxx>
    >>>>>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
    >>>>>>
    >>>>> _______________________________________________
    >>>>> dsdp-dd-dev mailing list
    >>>>> dsdp-dd-dev@xxxxxxxxxxx <mailto:dsdp-dd-dev@xxxxxxxxxxx>
    >>>>> https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
    >>>>>
    >>>> _______________________________________________
    >>>> cdt-dev mailing list
    >>>> cdt-dev@xxxxxxxxxxx <mailto:cdt-dev@xxxxxxxxxxx>
    >>>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
    >>>>
    >>> _______________________________________________
    >>> dsdp-dd-dev mailing list
    >>> dsdp-dd-dev@xxxxxxxxxxx <mailto:dsdp-dd-dev@xxxxxxxxxxx>
    >>> https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
    <https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev>
    >>> _______________________________________________
    >>> dsdp-dd-dev mailing list
    >>> dsdp-dd-dev@xxxxxxxxxxx <mailto:dsdp-dd-dev@xxxxxxxxxxx>
    >>> https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
    >>>
    >> _______________________________________________
    >> cdt-dev mailing list
    >> cdt-dev@xxxxxxxxxxx <mailto:cdt-dev@xxxxxxxxxxx>
    >> https://dev.eclipse.org/mailman/listinfo/cdt-dev
    >>
    >
    > _______________________________________________
    > cdt-dev mailing list
    > cdt-dev@xxxxxxxxxxx <mailto:cdt-dev@xxxxxxxxxxx>
    > https://dev.eclipse.org/mailman/listinfo/cdt-dev
    >
    _______________________________________________
    cdt-dev mailing list
    cdt-dev@xxxxxxxxxxx <mailto: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


Back to the top