Re: question about breakpoints

[Fernando Nasser <fnasser at cygnus dot com>]

Tom Tromey wrote:
> 
> 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.
> 

I will, after the CLI is changed to use it.  It currently shares the output
generation code.

The programs that use the MI must only rely that the fields they use will be
kept, they don't care about things that are added.  But while the CLI uses the
same code to print output, the contents and order are fixed.  This is relaxed
whenever a CLI command is fixed.  This is on the works, but will still take some
time.


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

No, and nobody said that.

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

"b function" seems to be one that this code will always guess right.

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

Trying to keep breakpoints between debugger invocations is, by definition,
trying to be smart.

And, BTW, this is not even in our TODO list and we have several higher
prioroty items to tackle.

I would suggest discussing this at a later time as it seems to be a rather polemic
topic.  I have seem such discussion before and this will be a long thread.
Unfortunately this was before this list was created so we don't have the 
archives and I also believe several of the discussions were on physical meetings.




-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9