Re: Library interface to GDB

[toddpw@wrs.com (Todd Whitesel)]

> I think it's really bad news to have code parsing output intended for
> humans.

Agreed. I've worked on debugger products that parsed the output of the
HP In-Circuit emulators' terminal interface, and it's a losing battle.

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

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

API yes, but not necessarily function calls.

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

The API to GDB basically takes two forms:
    - send a character to feed to readline for a command-line session
	(currently only one, but there's no fundamental reason why readline
	and the command logic couldn't be made instantiable with each instance
	getting its own value history and thread settings and so on).
    - send complete command string to be executed in a separate I/O context
	so that the output can be returned. This might need environment info
	like the thread ID and such.

It wouldn't be hard to add a GDB option that creates a socket connection
to another process, and accepts input over it. There would have to be a
simple wrapper format so that the various channels (key input, command input,
stdout, error(), warning(), protocol output, etc) could be distinguished.

-- 
Todd Whitesel
toddpw @ wrs.com