This is a substantiative list, I'll do my best to answer your questions
below:
Janees Elamkulam wrote:
Hi,
Thanks Pawel and Francois
May be i should give more details of what i am trying to do. I am currently
investigating on supporting DSF based debugger for our tool. We would like
to add break point on target, that is not added by the user through editors
and also retrieve information from the target (like call stack).
[Our Tool] <---interact_with---> [DSF] <----> [target C/C++ debugger, like
GDB or another debugger]
To achieve this (talking to different debuggers), we need a common
interface. For example : creating a break point. The service api for this
is
IBreakpoints.insertBreakpoint(IBreakpointsTargetDMContext, Map<String,
Object>, DataRequestMonitor<IBreakpointDMContext>)
To call this api I need a IBreakpointTargetDMContext, Map and
DataRequestMonitor. How to create these parameters when i dont know the
which DSF C/C++ debugger is running and all I have is a handle to ILaunch
and Dsfsessions. The keys for Map is not defined by the framework. I had a
look at the GDB reference implementation. It define the map keys itself so
there is no standard in here.
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.
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.
GDB reference example does not seem to follow BreakpointMediator and
AttributeTranslator frameworks. (I could be wrong here, i have just started
digging into dsf and gdb reference implementation source code).
Is there a plan to standardize these for C/C++ DSF based debuggers ?
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.
So given a File, line number, how do i add a line break point. In CDI i
can do this directly from the ICDebugTarget by adapting to ICDITarget,
which has all the capability required. Is there a way to get similar
functionality for controlling the target in DSF ?
The IBreakoints service is it.
I have some more queries
1. How to retrieve call stack and variables from the target ? What is the
starting point for traversing the data model ?
The starting point for the debug data model is also intentionally
vague, this is because it is an area where different debuggers differ a
lot. So for the DSF-GDB implementation there is a method in GDBControl
to get a data model context (DMC) representing the back end. In DD 1.0
release, this context directly implemented the
IRunControl.IContainerDMContext, which is the parent context in the run
control contexts hierarchy, as well as other context interfaces used by
other services. In 1.1 release, the picture got a little more
complicated, because GDB supports multiple processes. So instead, the
GDBControl's context should be used to call the new IProcesses service
to retrieve the list of processes being debugged.
Yes this is rather complicated, but so are the use cases. I think if
you are developing a tool to interact with the debugger, rather than
trying to walk the debug data model top-down, you would be better of
acquiring the context from the selection in the UI (active debug
context), or from an event that triggers your tool.
2. How to check if a particular debug service is supported or not ?
In a given session you can request that service (from OSGI), if it's
not supported the given service will not exist.
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.
4. Is there any plan to support or link with CDI framework or any plan to
unify both ?
The plan is to make CDT more framework neutral, so that all the UI
elements which are only available with CDI can be used with DSF-based
debuggers as well. The two APIs are very different in philosophy and
implementation, it may be possible to implement one with the other but
I argued in the past that this would nullify the benefits of either
(simplicity in CDI and performance/extensibility in DSF).
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.
I hope this helps, if you have more questions, please keep asking :-)
-Pawel
Thanks
- Janees
(Emb
edde
d Re: [dsdp-dd-dev] Programmatically adding breakpoint on target.
imag
e
move Pawel Piech
d to to:
file Device Debugging developer discussions
: 12/11/2008 02:22 PM
pic0
4686
.gif
)
Sent by:
dsdp-dd-dev-bounces@xxxxxxxxxxx
Please respond to Device Debugging developer discussions
<dsdp-dd-dev@xxxxxxxxxxx>
Hi Janees,
There is actually a little more to this story: there are two breakpoint
related services. One is the lower level interface that Francois pointed
out, the other is a breakpoint manager synchronization service which
synchronizes the target breakpoints with the eclipse breakpoint database.
It is up to the implementation of the services to make sure that if a
client accesses the IBreakpoints interface directly, the synchronization
takes care to synchronize the Eclipse breakpoint database with the
corresponding changes. I know that with the example PDA debugger I did not
add support for this, but I can't remember whether the GDB debugger
implementation has it.
Cheers,
Pawel
Francois Chouinard wrote:
Hi,
DSF provides a generic interface (IBreakpoint) that should then be
implemented by a Breakpoint Service specific to the integrated
debugger. That I/F specifies the minimal set of functions that the
service should implement (add/remove, enable/disable, ...).
The GDB/MI reference implementation provides an example.
Hope this answers your question.
Best Regards,
/fc
On Wed, Nov 12, 2008 at 12:02 PM, Janees Elamkulam <
janees.ek@xxxxxxxxxx> wrote:
Hello,
Is there a common interface to programmatically add breakpoint on
the
target using DSF framework that work for all C/C++ Debuggers
integrated to
eclipse using DSF ?
- 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
_______________________________________________
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
|