Re: libGDB architecture

[Steve Williams <swilliam@cup.hp.com>]

Andrew Cagney wrote:

> [. . .]
>
> As I hinted above, when formumulating an overall plan we considered
> creating an entirely new interface (rather than evolving the old one).
> It was felt that by putting the emphasis on evolving the existing code
> it would be possible to both leverage (as a verb? :-) the existing
> testsuite and consolidate the existing code base.  Creating a new
> separate independant interface would have ment the duplication
> significant amounts of GDB.
>

Of course, another alternative is to create a programatic interface that
returns data stuctures instead of text buffers. Then one could create a
CLI that is just another client of libgdb (a consumer of returned data
stuctures) instead of having the CLI intertwined with internals code. This
would allow libgdb to return rich sets of information from which clients
(including CLI) could pick and choose from as they see fit.

But I imagine the above is considered too big of a reorganization of GDB.
But with Andrew's proposal, it seems that GDB will remain print oriented,
with returned text having to be parsed into some other usable
intermediate form. Though this will work for typical debugging tasks, I
don't know that it will scale well when GDB is used for applications with
numerous threads and for GUIs that want to do some intense data
visualization (e.g., an array visualizers, etc.). Already I've noticed that
the performance a GUI is not good when using piped GDB output with
annotations to deal with large amounts of target data.

--Steve Williams