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.

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


Back to the top