Re: libGDB architecture

[Ovidiu Predescu <ovidiu@cup.hp.com>]

Hi Andrew,

On Mon, 06 Sep 1999 17:34:34 +1000, Andrew Cagney <ac131313@cygnus.com> wrote:

> > Sorry for being so late, but only now I had some time to read through the
> > libGDB architecture proposal thread.
> 
> My turn for being slow :-(

;-)

> The proposal is to identify a set of GDB operations and publish them
> using a, C based, function-call interface. An interpreter would be
> expected to implement bindings to that interface.
> 
> Initially, it is expected that some of those C-functions will be mapped
> directly onto existing interpreter commands  (gdb_lib_breakpoint_delete
> (int n) -> ``"delete %d", bp'').  Then, as GDB's internals are modified
> more direct implementations will be possible.

Aha, I think I understand where you're coming from!

Where does libGDB live in your proposal? Does it live in the client process,
aka outside GDB's process? If yes, then we are talking about two different
things. Your proposal defines a way for the client to make calls into GDB and
to be informed whenever some event occurs. You present to the client a set of C
functions that under the hood talk to GDB via a dedicated protocol. The user (a
programmer of course) can also modify the way the output comes from GDB by
changing the ui_out* functions you're talking about, but to be able to do this
he has to add these new functions and rebuild GDB.

My proposal is essentially the same set of C functions as yours but this time
they live in the GDB process. The API includes functions to access the GDB's
functionality and, in addition, it exports some of the internal GDB's
structures either as opaque pointers or as structures that contain general
enough members that don't modify over time. (So the answer to your question
"how close is close?" is "very close" ;-)

It is the above C API that is exposed to various interpreted languages using
SWIG. However both the glue code and the interpreter live in the same process
space with GDB.

In my proposal libGDB exposes only the GDB internals and it is not concerned at
all with how this data is passed between GDB and an external process. However,
once you have an interpreter built in GDB you could expose the internals using
various mechanisms: with CLI/ annotations as today, using Corba, RPC, XML-RPC,
HTTP/HTML or whatever else the user wants to use.

Could you please clarify the above point? If my understanding is not right,
then I have to read again all the messages on this thread to get a better
understanding of your proposal ;-).

Greetings,
Ovidiu