Re: libGDB architecture

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

On Thu, 09 Sep 1999 00:08:03 +1000, Andrew Cagney <ac131313@cygnus.com> wrote:

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

Who are these "most interpretative languages" ;-)? All these languages have
primitive data types that are ultimately represented as C structures for
efficiency. Even in Scheme building a list as a string and passing it to the
interpreter to be parsed at runtime is much slower than creating an atomic data
type that's represented as a structure.

> 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 this is exactly what I want ;-)! I want full access to GDB internals from
an interpreted language. Of course presented in a nice OOP way, having all the
objects garbage collected in the interpreter and all the nice features such a
language has. This is the only way to let a knowledgeable user do what he
wants, the only way we can have people extend GDB without going in the C code
and dealing with the problems that we have. Look at how Emacs exposes its
internals to Lisp, isn't that really nice? ;-)

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

I think a nicer approach is to have a function that simply returns the buffer
that contains the read memory. If this function is available to the client you
eliminate a malloc()/memcpy() operation.

Another problem with the printing model is that different clients may be
interested in different things. Lets take for example getting the backtrace.
The command line gdb prints the name of the function and the name and values of
the arguments. However a GUI client may only print the name of the functions
and defer printing the name and values of the arguments until the user actually
selects a frame. This is a huge improvement in some cases, especially with big,
recursive programs. We had a customer that had exactly this problem. They had a
huge recursive program and they were trying to get the location that called the
recursive function. I don't remember how many _hours_ it took them to find out
the result, but it was more than a working day anyway (> 10 hours). A "fast"
backtrace function that ignored printing the arguments gave them 10 times
faster results. Still not fast enough IMO...

The point here is that we need to have a clear distinction between computation
and printing, otherwise the same pieces of functionality are duplicated all
over the place just to print slightly different results. Having a generic
ui_out* function scheme doesn't solve these problems.

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

Also, having access to the internal data structures of GDB in the client is
faster than malloc()/memcpy() ;-).


Greetings,
Ovidiu