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:
<snip>
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
IBreakpointTargetDMContext.
In the test plugins i found that this is done by getting command control
service and then its context.
ICommandControlService commandControl = fServicesTracker
.getService(ICommandControlService.class);
fBreakpointsDmc =
(IBreakpointsTargetDMContext)commandControl.getContext();
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.
<snip>
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.
<snip>
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.
Cheers,
Pawel
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.
Regards,
- Janees
_______________________________________________
dsdp-dd-dev mailing list
dsdp-dd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
|
