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

["Mikhail Khodjaiants" <mikhailk@xxxxxxx>]

----- Original Message -----
From: "Tom Tromey" <tromey@xxxxxxxxxx>
To: <cdt-debug-dev@xxxxxxxxxxx>
Sent: Friday, July 19, 2002 5:17 PM
Subject: Re: [cdt-debug-dev] First draft of CDI is posted.


> Tom> I don't see a way to save a breakpoint.  This is doable, after a
> Tom> fashion, with an ICLocationBreakpoint (get the location and use
> Tom> that), but even this is problematic.
>
> Mikhail> The Eclipse framework associates breakpoints with the project
> Mikhail> resources. For instance, the location breakpoint in Eclipse
> Mikhail> is a marker associated with some line in the source file. The
> Mikhail> framework saves this information between sessions. Client can
> Mikhail> always obtain a list of breakpoints associated with your
> Mikhail> project, so there is no need to save it as a session
> Mikhail> attribute.
>
> Ok, thanks.  Assuming that markers intelligently follow edits, this
> could be even more useful than saving the text the user entered
> (obviously this wasn't possible to implement in Insight, as edits took
> place outside the application).  Whether it actually is, in practice,
> I'll be interested to find out.
>
> It seems like there must also be an event indicating that a new
> breakpoint has been created.  The user might create a breakpoint using
> "b main" in the console window, and this information must propagate to
> the UI.
>

The result of "b main" can be used as a notification that a breakpoint is
created.

> I do wonder whether anything other than simply saving the user-entered
> text will be useful for "b *addr" breakpoints.  This feature is not
> widely used by people debugging natively (in my experience anyway), so
> maybe it doesn't matter yet.
>

We solved this problem in our IDE by associating the address watchpoint with
the executable instead of  the source file.

> Mikhail> Insight is a graphical representation of the debug
> Mikhail> session. In IDE you can set a breakpoint before the session
> Mikhail> is started and the ICSession object hasn't created yet.
>
> Ok.  But it is less useful to let the user set a breakpoint where it
> doesn't make sense to set one, for instance in the middle of a comment
> (or "#if 0" code).  It seems to me that it would be more friendly,
> UI-wise, to present this information to the user when it is available.
>

Agree. But this is a responsibility of the parser.

> Tom> What would ICSharedLibrary be used for?  Wouldn't you need an event
to
> Tom> indicate that a new shared library has been loaded?
>
> Mikhail> We are planning to have a view that shows shared
> Mikhail> libraries. This is the event we would like to see in gdb/mi.
>
> What would such a view be used for?
> I don't recall ever looking at this information while debugging.
>

It could be just a console that displays the messages from the debugger not
a special view for the shared libraries.

>
> Also, I think it would be safe to remove catchpoints from the initial
> set of interfaces.  I think catchpoints, if they work at all in gdb,
> work only on HP-UX.
>

We don't have to use this interface in our gdb implementation. But, for
example, Windows generates a debug event when an exception occures.

> Tom
> _______________________________________________
> cdt-debug-dev mailing list
> cdt-debug-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
>