Re: [cdt-debug-dev] First draft of CDI is posted.

[Tom Tromey <tromey@xxxxxxxxxx>]

>>>>> "Mikhail" == Mikhail Khodjaiants <mikhailk@xxxxxxx> writes:

Mikhail> The first draft of CDI is in org.eclipse.cdt.debug.core.

I read through this.  I have a few preliminary questions and comments.
There are more to follow as I dig deeper into the details.  I'm sure
Keith will have comments too...

Let me say first of all that I think overall this interface is great.
By the end of the email you might not believe I think that :-), but
keep in mind that my comments are really just details, and overall the
structure here looks good to my eye.


My first question is how we will save state between debug sessions.  I
looked at this first since I wrote some session-saving code for
Insight, so I'm familiar with the problem.

I don't see a way to save a breakpoint.  This is doable, after a
fashion, with an ICLocationBreakpoint (get the location and use that),
but even this is problematic.

I think it is important to save breakpoints according to the way that
they are specified.  For instance, the user might set a breakpoint on
a function ("b foo::bar").  In this case, you want to keep that
information -- translating this into a location-based breakpoint means
that when the information is reloaded, it could be incorrect (the
function might move around in the file).

I recommend adding a method to ICBreakpoint that returns the original
breakpoint specification.  This information can then be used to
restore the breakpoint later.  Something like:

    /**
     * Returns a String representing the breakpoint.
     * This String can be used to recreate this breakpoint later.
     * @returns a specification which can be used to re-create
     * the breakpoint in a future session
     */
    String getSpecification();

Then a corresponding method is needed in ICBreakpointManager:

    /**
     * Create a breakpoint given an arbitrary breakpoint
     * specification.
     * @param spec - the breakpoint specification
     * @returns a newly-created breakpoint
     * @throws CDIException on failure
     */
    ICBreakpoint setBreakpointFromSpecification (String spec)
        throws CDIException;

I think ICLocationBreakpoint should just be removed, and its sole
method moved into ICBreakpoint.  I don't understand why one would want
them to be separate.


I don't see a way to set or get the inferior's command-line arguments.
Likewise for the current working directory.  Both these things are
nice to save in a session.

Maybe these are handled by ICSession.setAttribute()?  I wasn't sure.
If so, then the standard names for such attributes must be documented.
If not, I suggest a couple new methods on ICSession.


Insight also saves the current directory search list (for source
files); this is easy with the current framework.


I noticed that ICTarget.getProcess() returns a Process.  This seems
like an unusual choice to me.  When would we use this Process object?
Are the Process methods really relevant and useful?  If we do keep
this, then we might as well remove ICTarget.getOutputStream() and
friends, as they are redundant.


Insight's source window display shows all the executable lines -- it
puts a dot next to lines that correspond to actual code.  This makes
it very easy to see where a breakpoint can be placed (in fact the dot
acts as a kind of button to set a breakpoint).  I don't see a way to
get this information in the current interfaces.


I don't see a way to send raw debugger commands down.  Something like
this will be necessary to make a console window.  This is tricky since
you'd also need a way to represent the output from the debugger.


I'll let Keith comment on the variable stuff in cdi.model; he's really
the expert there.


What would ICSharedLibrary be used for?  Wouldn't you need an event to
indicate that a new shared library has been loaded?

Tom