Re: gdb/remote - I/O

[Grant Edwards <grante at visi dot com>]

On Wed, Mar 28, 2001 at 11:54:15AM -0500, Frank Ch. Eigler wrote:

> : Most targets, even the cheap eval boards available for low end
> : microcontrollers have more than one I/O channel, so I use one for
> : GDB and another for system I/O.
> 
> From the point of view of test suites and similar automated control,
> the fewer physical connections, the better.  Several remote debugging
> protocols include console I/O already; we would like to finally bring
> "remote" closer.
> 
> : But if I needed to route I/O through GDB, I think I'd want some-
> : thing richer than a single serial i/o stream.  Perhaps some sort of
> : lightweight filesystem layer with open/read/write/close primitives.
> : [...] If we're going to change the protocol, why not make it something
> : richer than a single stream?  [...]
> 
> Yes, this would be a worthwhile exercise, but is way outside
> the realm of reasonably small extensions of the remote
> protocol.

FWIW, RDI defines several independent comm channels between
host and target that are multiplexed into one data stream. The
RDI target code supports open/read/write/close semantics for
using the "semi-hosting" channel (or whatever it's called) to
open/read/write file descriptors.  I'm not recommending RDI as
a good model -- RDI is an overly complicated protocol even
considering the features that are supported (like
semi-hosting).

I don't know how well the semi-hosting stuff works, but it's
there as an example of how ARM Ltd. addressed the problem.

-- 
Grant Edwards
grante@visi.com