Re: libGDB architecture

[Andrew Cagney <ac131313@cygnus.com>]

Steve Williams wrote:
> 

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

We thought about that but concluded that most interpretative languages
are more interested in list like structures so a mechanism for
constructing lists (the way the client wanted) was of most benefit.

We also felt that if we were going to return structs then perhaphs we
should just open up the entire GDB internals (scary thought ... :-).

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

Under the model if you ask for a chunk of memory then eventually gdb
could make a sequence of calls like:
	ui_out_raw (....., "memory", buf, sizeof_buf);
and the client side of ui_out_raw() would be expected to save (copy)
that buffer as part of the accumulated result.  (Disclaimer - we've not
thought hard about someone wanting to do large memory reads).

Hmm,

	o	at present GDB doesn't do much thread
		caching (it is still very single thread)
		and this is considered an definite area
		in which GDB could be improved regardless
		of the above :-)

	o	As an accademic exercise it could be interesting
		to persue idea's that reduced the amount of
		memory shuffling gdb does when it goes to
		display memory values - could GDB map
		in the targets address space and access it
		directly?

Still, another malloc()/memcpy() has to be significantly faster than any
pipe'd interface :-)

	enjoy,
		Andrew