Re: libGDB architecture

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

Stan,

I don't plan to export all the idiosyncrasies used internally in GDB, I never
said that. I think however that we can safely expose things that are generic
enough so that they don't change over time (or at least we don't expect them to
;-).

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.

In the case of breakpoints for example, we would have something like this in
libgdb.h:

typedef void * CORE_ADDR;

struct breakpoint *new_breakpoint_at (CORE_ADDR address);

void enable_breakpoint (struct breakpoint *breakpoint);
boolean breakpoint_enabled_p (struct breakpoint *breakpoint);

void disable_breakpoint (struct breakpoint *breakpoint);
boolean breakpoint_disabled_p (struct breakpoint *breakpoint);

int breakpoint_number (struct breakpoint *breakpoint);
CORE_ADDR breakpoint_address (struct breakpoint *breakpoint);
int breakpoint_line_number (struct breakpoint *breakpoint);
const char *breakpoint_source_file (struct breakpoint *breakpoint);

struct breakpoint **all_breakpoints (void);

And so on for all the functionality that we want to export. 

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.

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.

The breakpoint example above is pretty simplistic, but most of the API looks
like this. There are some questions that we still need to ask when we come down
to values and types, depending on what level of manipulation we want to have
here.

I will post a design design document in the next few days describing this
proposal.

Regards,
Ovidiu

On Wed, 8 Sep 1999 12:17:59 -0700, Stan Shebs <shebs@cygnus.com> wrote:

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