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.

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

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 set
of properties, which is reflected in platform by the use of IMarker
and named attributes.  Since there are so many different types of
breakpoints, defining a common set of properties could reduce the
flexibility of the API.  So, the definition of attribute names and
expected values is up to the implementation, although in practice we
expect that mostly the same attributes used with the breakpoint's
marker would be used for this attribute map.

That is right, but we could have parallel definition for common kind of
breakpoints like
line and function breakpoint by defining the key for the breakpoint type
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 use
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, which
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 to
use the same breakpoint objects, e.g. CDT breakpoint objects, then
they are most likely to use the attributes defined by those breakpoints.
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 control
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, this
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 numbers
were i can read about design like how a Step command works. Is the any
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.  At
the CDT summit we discussed re-using the launch configuration type
kind of as a place holder, where different debuggers can link in
different launchers.  The appropriate launcher would be selected
automatically by the framework depending on the context of the
launch (active project, etc.) and the user could override this as
needed.  I plan to investigate this in CDT after the DD project is
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 specific
information from the launch ?

I'm not entirely sure what information you have in mind, but DSF
itself (also purposely) doesn't integrate with the launch APIs
directly.  Instead, it is the job of DSF implementations (such as
the one for GDB) to implement this integration.  The reason is that
not all debuggers necessarily fit the launch paradigm (e.g. hardware
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, it
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 will
be more questions :-)

Thanks a lot.


- Janees

dsdp-dd-dev mailing list

Back to the top