Re: Library interface to GDB

[jtc@redback.com (J.T. Conklin)]

>>>>> "Todd" == Todd Whitesel <toddpw@wrs.com> writes:
Todd> Agreed. I've worked on debugger products that parsed the output
Todd> of the HP In-Circuit emulators' terminal interface, and it's a
Todd> losing battle.

Todd> HP themselves tried to write a gasket that would API-ify the
Todd> emulators, so that client programs would not have to deal with
Todd> the emulator output.  This was cancelled after a couple years.

>> A debugger GUI should use an API, not AI. :)

Todd> API yes, but not necessarily function calls.

Todd> I rather like the idea of a "protocol" command in GDB whose
Todd> subcommands produce machine-readable output.

Regardless of whether the GDB API is implemented by traditional
function-calls; a wrapper layer that interacts with the existing CLI;
a machine parsable protocol; or some other RPC mechanism, I believe a
more fundemental question remains: what level of abstraction will the
API present.  After that question is resolved, we can discuss what the
specific calls will be and how the API will be implemented.

I think that we would want a fairly high level of abstraction, but
perhaps much less than what is currently provided by the CLI.  It is
my impression that systems that sit atop GDB and interact via the CLI
sometimes must do a lot of work to do simple things.  Perhaps someone
who has actually worked on/with such interfaces can share their
experiences?

One way to start might be to start breaking down the things that GDB
does into broad categories.  Once that list is complete, we could
refine and layer those categories into a heirarchy.  In the end, I
think we'd have the raw information necessary to make design
decisions.

For example:

Memory Operations
	read memory @ address w/<operand width>
	write memory @ address

Register Operations
	read register
	write register

Symbol Operations
	read symbol file
	convert address to symbol
	convert symbol to address

Execution Options
	next
	ni
	step
	si
	continue

Breakpoint Options
	create breakpoint
	delete breakpoint
	enable breakpoint
	disable breakpoint

...

This is just a sample I whipped out off the top of my head.  Going
through the code, the documentation, etc. would yeild a more complete
list.

I'm not sure I have enough time to spearhead such a effort, but it
seems that a lot of these categories could be taken on independently
or in small groups.  As a result, it shouldn't take that long to put
something together...

	--jtc

-- 
J.T. Conklin
RedBack Networks