Re: question about breakpoints

[Fernando Nasser <fnasser@cygnus.com>]

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