This is the mail archive of the insight@sources.redhat.com mailing list for the Insight project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: question about breakpoints


Fernando> Unfortunately this will make my life more difficult
Fernando> afterwards.  The corresponding MI call has the contents
Fernando> frozen because of the CLI.

If you really can't add new fields as time goes on then it sure seems
brittle, doesn't it?  I took a brief look through the mi docs and I
don't see where it says that programs can rely on the fields remaining
fixed.

Fernando> But I don't think you (or whoever adds saved breaks) should
Fernando> necessarily use the same specification as the user (who
Fernando> would have most probably clicked on the source window, but
Fernando> not necessarily).  The debugger must use some smart
Fernando> algorithm to maximize the chances that the breakpoint is
Fernando> still meaningful.  This means using all the information
Fernando> available, which is already in the current command.

There is no way to ensure that the breakpoint will always be useful.

As a user I would expect that if I type `b function' in the console,
then when I reload the session I get a breakpoint on the function and
not at some random "useful" place.

In other words, it is easier to predict, and therefore use, tools
that are dumb than tools that try to be smart.

I agree that for breakpoints set via the GUI it might make sense to
apply some heuristic in some situations.  For instance if you use the
GUI to set a breakpoint on the first executable line of a function you
might choose to have the session interpret that as a breakpoint on the
function and not on a particular line.

As another example of why we need more information, consider the
language used to set a breakpoint condition.  This is stored in struct
breakpoint, but isn't printed out.  But I think we need this
information to correctly restore breakpoint conditions.

Finally, the information returned by the current
gdb_get_breakpoint_info command apparently can't be used to set
the breakpoint.  As a first try I made the code restore breakpoints
using "b file:line".  gdb claims to never have heard of the file
specified.  I wonder if the file name is being munged somehow before
return?

Fernando> This was discussed before with several engineers who were
Fernando> writing a GUI for GDB and they deemed the current output as
Fernando> sufficient for their implementation.

Do you have a pointer to this discussion?

Tom

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]