|Re: [dsdp-dd-dev] Programmatically adding breakpoint on target.|
I Janees, I'm resending this message again as you indicated that you
didn't receive it correctly last time.|
Janees Elamkulam wrote:
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.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.
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.
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.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 ?
The IBreakoints service is it.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 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.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 ?
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.
In a given session you can request that service (from OSGI), if it's not supported the given service will not exist.2. How to check if a particular debug service is supported or not ?
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.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
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).4. Is there any plan to support or link with CDI framework or any plan to unify both ?
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.5. Is there any change planned for launch to retrieve DSF specific information from the launch ?
I hope this helps, if you have more questions, please keep asking :-)
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
Back to the top