[
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 .
Regards,
- Janees
Re: [dsdp-dd-dev] Programmatically adding breakpoint on target.
Pawel Piech
to:
Device Debugging developer discussions
13/11/2008 05:06 PM
Sent by:
dsdp-dd-dev-bounces@xxxxxxxxxxx
Please respond to Device Debugging developer discussions
<dsdp-dd-dev@xxxxxxxxxxx>
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
_______________________________________________
dsdp-dd-dev mailing list
dsdp-dd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
