Re: libGDB architecture

[Ovidiu Predescu <ovidiu AT cup.hp dot com>]

On Thu, 16 Sep 1999 21:20:48 +1000, Andrew Cagney <ac131313@cygnus.com> wrote:

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

This is indeed a problem. However I think it could be solved pretty easily by
putting a reference count variable in each structure that we export. Stop,
stop, don't think that we need to change the memory handling policy inside GDB
once we've added this instance variable.

We don't need to do that. This refcount is set to one for each GDB internal
data structure that is exported by libGDB, at the time of its inception. When a
client imports such a structure, it increments the refcount. We then modify the
free() functions slightly, like this:

  mem->refcount--;
  if (mem->refcount == 0)
    free (mem);

Both GDB and the client can keep references to an object. When GDB disposes an
object that is still maintained by the client, the object doesn't simply
disappear. Both the client and GDB have to release the object for it to be
deallocated.

When GDB decides that an object is no longer needed, it removes the reference
to it and announces the client that the object became invalid. It's the client
responsibility to remove its reference to that object.

I looked on the TCL code but couldn't find what you're referring to. Maybe it
uses the same approach, in which case it should be simple for us to implement
libGDB.

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

I don't think this approach will work. A normal interpreted language uses some
sort of garbage collection, so if there's a reference to an object from some
part of the program, the object will not be deallocated. In this case will have
a stale handle, GDB thinks that the client no longer keeps a reference to that
object, while the client still has. The invalidation mechanism described above
should work fine in this case.

> > 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 :-)

I know, I looked at the code. That's why I proposed to extend the API you
implemented to be able to handle other clients as well. We want to do a similar
thing here for Python and it looks like Martin wants to do a similar thing for
Guile. It simply doesn't make sense for all of us to reinvent the wheel.

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

We simply need to make sure the functions in the libGDB API do no print
anything to the output. Sounds simple, but I know there's a lot of work
involved ;-).

Greetings,
Ovidiu

PS: We've been busy these days here and I couldn't find time to come up with my
proposal on libGDB. I hope the things will calm down at the beginning of next
week so I can work on it.

-- 
Ovidiu Predescu <ovidiu@cup.hp.com>
http://andromeda.cup.hp.com/  (inside HP's firewall only)
http://www.geocities.com/SiliconValley/Monitor/7464/