libgdb 1.0 was an abortive project of years ago. The theory was
to provide an API to gdb's functionality.
libgdb 2.0 is an ongoing effort to update gdb so that is
better able to support graphical and other environments.
libgdb development is on-going, its architecture is still
evolving. The following components have so far been identified:
The model that ties these components together is described below.
A client of
libgdb interacts with the library in two ways.
libgdbof any internal state changes (break point changes, run state, etc).
libgdb(using the ui-out builder) to obtain various status values from gdb.
libgdb could have multiple clients (e.g., a GUI supporting
the existing gdb CLI), those clients must co-operate when
libgdb. In particular, a client must ensure that
libgdb is idle (i.e. no other client is using
before responding to a gdb-event by making a query.
At present gdb's CLI is very much entangled in with the core of
libgdb. Consequently, a client wishing to include the CLI in
their interface needs to carefully co-ordinate its own and the CLI's
It is suggested that the client set
libgdb up to be bi-modal
(alternate between CLI and client query modes). The notes below sketch
out the theory:
cli-outbuilder using its own versions of the
ui-outbuilder that is only used while making direct queries to
When the client receives input intended for the CLI, it simply passes it
along. Since the
cli-out builder is installed by default, all
the CLI output in response to that command is routed (pronounced rooted)
through to the client controlled
gdb_stdout et. al. streams.
At the same time, the client is kept abreast of internal changes by
virtue of being a
The only restriction on the client is that it must wait until
libgdb becomes idle before initiating any queries (using the
client's custom builder).
gdb-events provides the client with a very raw mechanism that can
be used to implement an observer. At present it only allows for one
observer and that observer must, internally, handle the need to delay
the processing of any event notifications until after
finished the current command.
ui-out provides the infrastructure necessary for a client to
create a builder. That builder is then passed down to
when doing any queries.
event-loop, currently non-re-entrant, provides a simple event loop. A client would need to either plug its self into this loop or, implement a new event-loop that gdb would use.
The event-loop will eventually be made re-entrant. This is so that gdb can better handle the problem of some commands blocking instead of returning.
libgdb is the most obvious component of this system. It provides
the query interface. Each function is parameterized by a
builder. The result of the query is constructed using that builder
before the query function returns.