[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-debug-dev] First draft of CDI is posted.
|
----- Original Message -----
From: "Tom Tromey" <tromey@xxxxxxxxxx>
To: <cdt-debug-dev@xxxxxxxxxxx>
Sent: Friday, July 19, 2002 2:42 PM
Subject: Re: [cdt-debug-dev] First draft of CDI is posted.
> >>>>> "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.
>
Thank you.
>
> 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.
>
You are right. The method to save session's attributes should be added to
the session interface.
> 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.
>
The Eclipse framework associates breakpoints with the project resources. For
instance, the location breakpoint in Eclipse is a marker associated with
some line in the source file. The framework saves this information between
sessions. Client can always obtain a list of breakpoints associated with
your project, so there is no need to save it as a session attribute.
The ICLocationBreakpoint interface represents a breakpoint that exists
during the session. You can think about it as a number that gdb returns as a
result of the "break" command.
> 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;
>
There are two ways to set a breakpoint: from GUI and programatically. When
the breakpoint is set from GUI we get a marker that specifies it. To set a
breakpoint programatically the client has to call the
"setLocationBreakpoint" method.
> 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.
>
ICBreakpoint is a base interface for ICLocationBreakpoint, ICWatchpoint and
ICCatchpoint. They all share some basic functionality.
>
> 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.
>
You are right. We have to come up with the generic set of attributes and add
standard names for them.
>
> Insight also saves the current directory search list (for source
> files); this is easy with the current framework.
>
The search paths (for source files, shared libraries etc) are the attributes
of the debug session.
>
> 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.
>
Sorry, I forgot to remove it. I am going to do it right now.
>
> 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.
>
Insight is a graphical representation of the debug session. In IDE you can
set a breakpoint before the session is started and the ICSession object
hasn't created yet.
>
> 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 will add the getInputStream, getErrorStream and getOutputStream methods to
the ICSession interface.
>
> 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?
>
We are planning to have a view that shows shared libraries. This is the
event we would like to see in gdb/mi.
> Tom
Thank you very much for your comments.
Mikhail
> _______________________________________________
> cdt-debug-dev mailing list
> cdt-debug-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
>
