Re: [dsdp-dd-dev] Programmatically adding breakpoint on target.

[Janees Elamkulam <janees.ek@xxxxxxxxxx>]

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.


> 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 ?

>
> 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 ?


<snip>
>
> 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.

Thanks for this info, this helped to get idea on how to go forward.


> 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 ?


<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.

> 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