[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
libgdb
1.0 was an abortive project of years ago. The theory was
to provide an API to GDB's functionality.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
libgdb
2.0 is an ongoing effort to update GDB so that is
better able to support graphical and other environments.
Since 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.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
libgdb
Model
A client of libgdb
interacts with the library in two ways.
libgdb
of any internal state changes (break point changes, run
state, etc).
libgdb
(using the `ui-out' builder) to
obtain various status values from GDB.
Since libgdb
could have multiple clients (e.g. a GUI supporting
the existing GDB CLI), those clients must co-operate when
controlling libgdb
. In particular, a client must ensure that
libgdb
is idle (i.e. no other client is using libgdb
)
before responding to a `gdb-event' by making a query.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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
requirements.
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:
libgdb
.
cli-out
builder using its own
versions of the ui-file
gdb_stderr
, gdb_stdtarg
and
gdb_stdout
streams.
ui-out
builder that is only
used while making direct queries to libgdb
.
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 libgdb
observer.
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).
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
libgdb
components libgdb
has
finished the current command.
libgdb
when doing any queries.
The event-loop will eventually be made re-entrant. This is so that can better handle the problem of some commands blocking instead of returning.
ui-out
builder. The result of the query is constructed using that builder
before the query function returns.
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Please send FSF & GNU inquiries & questions to gnu@gnu.org. There are also other ways to contact the FSF.
These pages are maintained by the GDB developers.
Copyright Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111, USA.
Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
This document was generated by GDB Administrator on October, 18 2002 using texi2html