Re: Library interface to GDB

[Martin Baulig <martin@home-of-linux.org>]

toddpw@wrs.com (Todd Whitesel) writes:

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

I'd prefer a real function-call based API with real callbacks more
(something like the guile interface I'm currently writing ...)

-- 
Martin Baulig - martin@home-of-linux.org - http://www.home-of-linux.org