Re: libGDB architecture

[Andrew Cagney <ac131313 AT cygnus dot com>]

Ovidiu Predescu wrote:

> To be sure that people don't actually use our internal private data members, we
> can simply make the structures opaque pointers and provide functions that take
> them as an argument and perform the appropriate action. We can now come up with
> a header file, libgdb.h (that doesn't include any other GDB header file) and
> that defines the API we're exporting.

> struct breakpoint *new_breakpoint_at (CORE_ADDR address);

A consequence of handing out pointers to internal GDB data structures is
that GDB's internals and the external client need to reach a very clear
concensus over the life time of those objects.  I understand that tcl
has a mechanism that allows it and the low level code to keep a
reference count.

I strongly prefer to not go down that path.  Rather ``handles'' are
passed between GDB and the external client.  This would allow GDB to
sanity check anything comming in.  While GDB is expected to advise the
client when an object is dead, I expect GDB to trust the client to keep
its end of the bargin.

> The functionality that we export should be sufficient to be able to write
> programs in an interpreted language that could drive a full debugging session.
> Imagine that you would have to rewrite the whole testsuite in the interpreted
> language of your choice using this API, and you get a feeling of what needs to
> be exported.

We do that every day with tcl :-)

> The important thing here is that we need to make sure that all the functions in
> the API don't have any side effect of printing to any of the streams. The
> printing should be done instead in another set of functions, specifically
> designed for the GDB's interaction with the command line.

That is actually one of the things we've been worrying about :-) Getting
some level of control over what GDB outputs and when.

	enjoy,
		Andrew