Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [dsdp-dd-dev] Programmatically adding breakpoint on target.

Thanks Pawel,

I will send a separate email on use case for service over DSF .


- Janees

       Re: [dsdp-dd-dev] Programmatically adding breakpoint on target.          
       Pawel Piech                                                              
                     Device Debugging developer discussions                     
                                                            13/11/2008 05:06 PM 
       Sent by:                                                                 
      Please respond to Device Debugging developer discussions                  

Janees Elamkulam wrote:
      Hi Pawel,

      Thanks for the reply, It cleared lot of things ,
      please see my reply inline below.

      Pawel Piech <pawel.piech@xxxxxxxxxxxxx> wrote on 13/11/2008 11:11:45


            The ambiguity in the breakpoint attribute map is intentional,
            although we had a lot of interesting debate about this.  The
            idea is
            that a breakpoints, at the lowest common denominator, is just a
            of properties, which is reflected in platform by the use of
            and named attributes.  Since there are so many different types
            breakpoints, defining a common set of properties could reduce
            flexibility of the API.  So, the definition of attribute names
            expected values is up to the implementation, although in
            practice we
            expect that mostly the same attributes used with the
            marker would be used for this attribute map.

      That is right, but we could have parallel definition for common kind
      breakpoints like
      line and function breakpoint by defining the key for the breakpoint
      and value id for these.

      We could define keys for commonly used breakpoint attributes like
      file_name, line number, function_name etc.

      Of course, the framework will not enforce these, but implementers can
      these at their wish. I believe, if it is defined in framework, most
      of them
      are going to use these values were needed, than defining their own.

We actually did start doing this at one point, but we realized that we're
duplicating all the established contestants in platform's IBreakpoint,
ILineBreakpoint, etc., which was making our implementation more verbose.
Maybe we could just include a comment in the API that the attribute
constants should by convention come from the platform APIs?

            I suppose this doesn't really address your need of having a
            consistent interface across many different kinds of debuggers,
            I have to admit is a weakness of this API.  However, if you can
            assume that the debuggers you want to integrate with are going
            use the same breakpoint objects, e.g. CDT breakpoint objects,
            they are most likely to use the attributes defined by those

      Our break point is similar to CDT, but how do i create a
      IBreakpointTargetDMContext ? I.e if i know the full details of
      implementation and values to put in break point map, how do i create
      In the test plugins i found that this is done by getting command
      service and then its context.

                  ICommandControlService commandControl = fServicesTracker
                  fBreakpointsDmc =

      Is this always true or is it specific to MI implementation ?

It is specific to the implementation.  For example, currently GDB allows
breakpoints to be created at the global context.  I.e. all breakpoints
apply to all processes and threads, and this is true even for the latest
GDB version under development, where multi-process support is being
implemented.  Therefore, the breakpoint context is implemented by the
command control context, i.e. the context for the whole GDB session.
However in the future, GDB may decide to have separate breakpoint spaces
for different processes, in which case the breakpoint context will need to
be implemented by the process context.

The easiest thing to do when executing an action from the UI, is to take
the context on which the UI element is based on and search its ancestors
for the breakpoint context.

            Yes there is a bug (219604), to make this happen.  However,
            will require the BreakpointMediator to become more
            sophisticated and
            we'll probably need a good use case for this work.

      Thanks for this bug number, can you give me reference to other bug
      were i can read about design like how a Step command works. Is the
      architecture document ?

The best documentation that we have is in the tutorial that you probably
already have seen.  As continue to build momentum around this architecture
I hope to have time to write more tutorials and articles to more completely
document it.


            3. Is there a common UI existing / proposed for  launching
            C/C++ with DSF
            Debugger, similar to CDT launch config, were user can select
            the debugger
            from the drop down list

            No and I think even CDI is going to move away from that model.
            the CDT summit we discussed re-using the launch configuration
            kind of as a place holder, where different debuggers can link
            different launchers.  The appropriate launcher would be
            automatically by the framework depending on the context of the
            launch (active project, etc.) and the user could override this
            needed.  I plan to investigate this in CDT after the DD project
            moved there.

      Is there a service to retrieve all the dsf debuggers and their launch
      method ?

No I suppose there is not.  If we have a use case for this we could create
some kind of debugger registry where debuggers can identify themselves.


            5. Is there any change planned for launch to retrieve DSF
            information from the launch ?

            I'm not entirely sure what information you have in mind, but
            itself (also purposely) doesn't integrate with the launch APIs
            directly.  Instead, it is the job of DSF implementations (such
            the one for GDB) to implement this integration.  The reason is
            not all debuggers necessarily fit the launch paradigm (e.g.
            bringup debugging), so we didn't want to force this linking.

      DSF is very generic now, Defining standard for each domain (hardware,
      software) that it plan to address would be nice. Without a standard,
      will going to be difficult to provide additional service over DSF.

Parts of DSF are intended to be very generic.  For example the
org.eclipse.dd.dsf plugin really has nothing specific to do with debugging
except the name.  I think we need to understand better the use cases for
the services that could be built on top.  For the most part my focus in
this architecture has been on the common debugger views as the main client.
It's also true that DSF is still relatively young and we've already
received feedback pointing to some assumption which we made that could make
it more difficult for some implementations.  So we do plan to keep evolving
it to make it better.

            I hope this helps, if you have more questions, please keep
            asking :-)

      This did help a lot, I am still learning how DSF is working, so there
      be more questions :-)

      Thanks a lot.


      - Janees

      dsdp-dd-dev mailing list

dsdp-dd-dev mailing list

Back to the top