question about breakpoints

question about breakpoints

[Tom Tromey]

Today I've done a bit of work on making my session saving code also
save breakpoints and watchpoints.

I'd really like to access the `exp_string' and `addr_string' fields of
gdb's `struct breakpoint'.  Currently the Tcl interface gives me no
way to do that.

What is the preferred fix here?  One idea would be to introduce a new
Tcl command, like `gdb_get_breakpoint_info_x" (x == "extended", a
MS-esque naming choice).  Another idea might be to update
gdb_get_breakpoint_info (and all callers -- you can see why I might be
reluctant to do this).

Maybe there is another choice I'm missing?


I'm a bit concerned about the ad hoc nature of the gdb-specific Tcl
commands implemented in C.  There are a lot of these, but we need
more, and there doesn't seem to be any coherent guidelines governing
how they should act.  It leaves me questioning the long-term viability
of this approach.

I know the long term plan is to use MI and have gdbtk be a separate
process.  That's fine.  But even then we need some API to gdb.
Changing APIs during this transition is going to be very hard if there
is a lot of ad hoc code to update, especially when you consider that
this will have to be done on top of solving the other problems
inherent in the two-process approach.

Tom

Re: question about breakpoints

[Fernando Nasser]

Tom,

You are right that the interface commands were created ad hoc.  They were
created over time as needed.  This was unavoidable as there were no good
previous knowledge of what was needed.

This will be cleared with time.  As part of the "libgdb" project I have 
studied how all the GUIs accessed GDB data and one of the results of this
study was the current set of MI commands.  This study was revised by several
other people at the time, and it is supposed to be able to supply a functional
GUI with the necessary data.

With regards to the API, it was one of the things I did as part of my PhD work
some years ago.  However, GDB folks have decided that we will discuss the API
publicly in the GDB list when time is right.  One of the things that will be
taken into account is what the different interfaces to GDB will be using.
This includes Insight, other GUIs, the CLI (when properly separated) as well
as the planned script languages (GUILE and others).

For now let's just add what we need but using common sense.  Try to mimic the MI
as much as possible to facilitate things in the future.  Your proposed extension
to gdb_get_breakpoint_info is a good idea.  I guess you won't have time to
change all the callers, so you can create and use a gdbtk_get_breakpoint_info and
use it.  We get rid of the old gdb_get_breakpoint_info during the planned cleanup.

However, I would ask you not to use an array.
If you return a list of pairs you'll be providing exactly (or close to) what will be 
automatically provided by the tcl-out code in the future.  
In gdb/breakpoints.c you'll find the keys used for each field in the ui_out code.

Thanks.

Regards,
Fernando




Tom Tromey wrote:
> 
> Today I've done a bit of work on making my session saving code also
> save breakpoints and watchpoints.
> 
> I'd really like to access the `exp_string' and `addr_string' fields of
> gdb's `struct breakpoint'.  Currently the Tcl interface gives me no
> way to do that.
> 
> What is the preferred fix here?  One idea would be to introduce a new
> Tcl command, like `gdb_get_breakpoint_info_x" (x == "extended", a
> MS-esque naming choice).  Another idea might be to update
> gdb_get_breakpoint_info (and all callers -- you can see why I might be
> reluctant to do this).
> 
> Maybe there is another choice I'm missing?
> 
> I'm a bit concerned about the ad hoc nature of the gdb-specific Tcl
> commands implemented in C.  There are a lot of these, but we need
> more, and there doesn't seem to be any coherent guidelines governing
> how they should act.  It leaves me questioning the long-term viability
> of this approach.
> 
> I know the long term plan is to use MI and have gdbtk be a separate
> process.  That's fine.  But even then we need some API to gdb.
> Changing APIs during this transition is going to be very hard if there
> is a lot of ad hoc code to update, especially when you consider that
> this will have to be done on top of solving the other problems
> inherent in the two-process approach.
> 
> Tom

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

Re: question about breakpoints

[Tom Tromey]

Fernando> However, I would ask you not to use an array.  If you return
Fernando> a list of pairs you'll be providing exactly (or close to)
Fernando> what will be automatically provided by the tcl-out code in
Fernando> the future.  In gdb/breakpoints.c you'll find the keys used
Fernando> for each field in the ui_out code.

I assume you are referring to the function print_one_breakpoint.
I looked and it also doesn't print the fields I want.

Overall I think your plan sounds good though.

Tom

Re: question about breakpoints

[Fernando Nasser]

Tom Tromey wrote:
> 
> I'd really like to access the `exp_string' and `addr_string' fields of
> gdb's `struct breakpoint'.  Currently the Tcl interface gives me no
> way to do that.
> 

Sorry Tom, I missed the fact that these two are not ever printed.
In this case a new function would be in order.  I also missed the fact
that before the CLI is converted, we cannot add info to this commands
without having them printed as well (something not difficult to fix but
that we haven't added because it would eventually become unnecessary).

I thought you were going to save/reinsert breakpoints based on the symbolic
information rather than in the addresses.  That has a better chance of surviving
between debugger invocation. In that case you could be able to reconstruct
a "linespec" from the print_one_breakpoint info (i.e., our gdb_get_breakpoint_info).

Regards,
Fernando

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

Re: question about breakpoints

[Tom Tromey]

Fernando> Sorry Tom, I missed the fact that these two are not ever
Fernando> printed.  In this case a new function would be in order.

I think converting the existing function and then adding new output to
it is the best approach.

Fernando> I thought you were going to save/reinsert breakpoints based
Fernando> on the symbolic information rather than in the addresses.

Yes.  My understanding is that `addr_string' and `exp_string' are the
original strings used by the user to set the breakpoint or expression
(resp).  I say this because that is what the comments in breakpoint.h
imply.  Am I wrong?

Fernando> In that case you could be able to reconstruct a "linespec"
Fernando> from the print_one_breakpoint info (i.e., our
Fernando> gdb_get_breakpoint_info).

I don't think so.  If the user types "b function" there is no way to
differentiate that from "b file:line".  In both situations we get all
that information from gdb_get_breakpoint_info.

Tom

Re: question about breakpoints

[Keith Seitz]

Tom Tromey wrote:
> 
> Fernando> Sorry Tom, I missed the fact that these two are not ever
> Fernando> printed.  In this case a new function would be in order.
> 
> I think converting the existing function and then adding new output to
> it is the best approach.
> 

I'm with Tom on this one. This is one of those really, really old
functions from the original gdbtk which has survived into this "new"
version. Its intent is to provide all the information there is about a
breakpoint.

I believe that this function should be extended to include the
information about the breakpoint, since this is the function's purpose.

Of course, there is an argument here to be made that we should
restructure gdbtk commands to look more like tcl commands, i.e.,
"breakpoint set", "breakpoint enable", "breakpoint disable", "breakpoint
info", etc. Just a thought. :-)

> Fernando> I thought you were going to save/reinsert breakpoints based
> Fernando> on the symbolic information rather than in the addresses.
> 
> Yes.  My understanding is that `addr_string' and `exp_string' are the
> original strings used by the user to set the breakpoint or expression
> (resp).  I say this because that is what the comments in breakpoint.h
> imply.  Am I wrong?

I believe that this is correct. This is exactly what you would want. (At
least, that is the way I remember it, too. I seem to recall that this
bit me once or twice while trying to do something.)

My $0.02.
Keith

Re: question about breakpoints

[Fernando Nasser]

Keith Seitz wrote:
> 
> Tom Tromey wrote:
> >
> > Fernando> Sorry Tom, I missed the fact that these two are not ever
> > Fernando> printed.  In this case a new function would be in order.
> >
> > I think converting the existing function and then adding new output to
> > it is the best approach.
> >
> 
> I'm with Tom on this one. This is one of those really, really old
> functions from the original gdbtk which has survived into this "new"
> version. Its intent is to provide all the information there is about a
> breakpoint.
> 
> I believe that this function should be extended to include the
> information about the breakpoint, since this is the function's purpose.
> 

Unfortunately this will make my life more difficult afterwards.
The corresponding MI call has the contents frozen because of the CLI.
I had a function to add extra fields but I was asked to try to avoid
adding it.  So I would prefer a separate function for these fields.

Furthermore, the first set (in the current command) is user oriented info,
while the second one would be for some non-visible internal hack.
I don't think we should mix these much (MI has parameters of the "-X"
kind -- we could add one to the command if necessary, but not alter the
current result).

And I disagree with the way this is supposed to work (see below). 


> Of course, there is an argument here to be made that we should
> restructure gdbtk commands to look more like tcl commands, i.e.,
> "breakpoint set", "breakpoint enable", "breakpoint disable", "breakpoint
> info", etc. Just a thought. :-)
> 
> > Fernando> I thought you were going to save/reinsert breakpoints based
> > Fernando> on the symbolic information rather than in the addresses.
> >
> > Yes.  My understanding is that `addr_string' and `exp_string' are the
> > original strings used by the user to set the breakpoint or expression
> > (resp).  I say this because that is what the comments in breakpoint.h
> > imply.  Am I wrong?
> 
> I believe that this is correct. This is exactly what you would want. (At
> least, that is the way I remember it, too. I seem to recall that this
> bit me once or twice while trying to do something.)
> 

I haven't looked at what `addr_string' and `exp_string' are.  The names seem
to be badly chosen.

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

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



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

Re: question about breakpoints

[Tom Tromey]

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

Re: question about breakpoints

[Fernando Nasser]

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

Re: question about breakpoints

[Tom Tromey]

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

It should be on the to-do list.  The to-do list should also be checked
in.

Fernando> I would suggest discussing this at a later time as it seems
Fernando> to be a rather polemic topic.

Ok, I'll skip it.

Tom

Re: question about breakpoints

[Tom Tromey]

Keith> Of course, there is an argument here to be made that we should
Keith> restructure gdbtk commands to look more like tcl commands,
Keith> i.e., "breakpoint set", "breakpoint enable", "breakpoint
Keith> disable", "breakpoint info", etc. Just a thought. :-)

This would be nice.  Consider if you are setting a breakpoint right
now from Tcl.  I don't think there is an easy way to find the number
of the breakpoint you just created (eg if you want to immediately
disable it).  In the session loading code I assume it is the highest
numbered breakpoint.  This is ugly though.  A real `breakpoint'
command could just return this info without much fuss.

Tom

Re: question about breakpoints

[Fernando Nasser]

Tom Tromey wrote:
> 
> Keith> Of course, there is an argument here to be made that we should
> Keith> restructure gdbtk commands to look more like tcl commands,
> Keith> i.e., "breakpoint set", "breakpoint enable", "breakpoint
> Keith> disable", "breakpoint info", etc. Just a thought. :-)
> 
> This would be nice.  Consider if you are setting a breakpoint right
> now from Tcl.  I don't think there is an easy way to find the number
> of the breakpoint you just created (eg if you want to immediately
> disable it).  In the session loading code I assume it is the highest
> numbered breakpoint.  This is ugly though.  A real `breakpoint'
> command could just return this info without much fuss.
> 

Well, some of us have a devious plan to have a Tcl script language to gdb
(although others want GUILE, other Perl, others something else).
These script languages will be calling "libgdb" functions.  But this
is subject for another list and it is not the proper time either.  There is
some ground work to be done before that is possible.

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