Re: libGDB architecture

[Stan Shebs <shebs@cygnus.com>]

   Date: Mon, 06 Sep 1999 22:51:48 -0700
   From: Ovidiu Predescu <ovidiu@cup.hp.com>

   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" ;-)

The flaw in the ointment here is that GDB's internal data structures
are just that - internal.  They were not designed to be exposed
outside of GDB's control structure.  Now in practice, some things are
easy, such as the enable bit for breakpoints.  But what about
breakpoint numbers?  Should every libgdb client be expected to deal
with negative numbers, and to know that these are "internal"
breakpoints?  What about the extra frame info?  Its format varies
wildly depending on target arch, and varies from release to release as
well, and yet for many architectures you can't make sense of a frame
without it.

So while I think we want to make the interface as close to GDB
internals as possible, it would be irresponsible to say "here, just
include frame.h and breakpoint.h".  We do need to define an API that
can remain fairly stable while things churn underneath.  You will need
this in order to cope with the next round of GDB changes; for
instance, ideas on the horizon include multi-process debug (inferior
state globals disappear) and non-flat memory maps (CORE_ADDR becomes a
struct).  I'm not willing to be told "you can't change anything
anymore because it would break libgdb", and I don't think you want to
be stuck with an old version of GDB because you don't have the
resources to update client code that depends on evolving internals.

One thing that I'd like to see at this point is a more concrete
description of what libgdb clients ought to have at their disposal.
Does the set of objects and operations look more like an abstractified
version of the command-line interface, and more like an abstraction of
existing internals?  It's going to be hard to make a good choice
unless we have a concrete list of object types and a concrete list of
desired properties/operations.  Also, the list needs to be fairly
complete, so that one's analysis isn't misdirected by single cases,
such as breakpoint objects.  My intuition is that the overall list
should look more like the command-line interface, but I've never yet
seen a complete list that I can pore over and understand.

								Stan