gdb/remote - I/O

gdb/remote - I/O

[Andrew Cagney]

Hello,

The existing remote protocol doesn't support input vis: GDB -> target
(ignoring the ``target cisco'' hack that just sends raw characters).  I
think the current semantics for output are also weak and I'd like to
change them.  In the below I'll try to sketch out the basic idea.

As way of background, the remote protocol is not symetric.  GDB
initiates everything and then the target (eventually) responds.  For
instance:

	-> g (read registers)

	<- 12345678123456781234567812345678
	   (register bytes in hex)

A target is continued with:

	-> c (continue)

	(time passes)

	<- T....
	   (stop with info)

To halt the target:

	-> c (continue)
	(time passes)
	<BREAK>
	(time passes)
	<- T.... (stop)

Where <BREAK> is the CNTRL-C character but could be some other
out-of-band character.
Appart from the ``O'' (output) packet, the target never initiates
anything.


Output:

I'd like to change the protocol so that the output mechanism is
synchronous.  That is, instead of:

	-> c (continue)
	<- O....  (hex output)
	<- O....  (more hex output)
	<- T... (stop)

The output mechanism is treated like any other continue response.  That
is, it halts the target and waits for further input vis:

	-> c (continue)
	<- o<output> (implied halt)
	-> c (continue)
	<- o<more-output> (implied halt)
	-> c (continue)
	<- T... (stop)


Pragmatics:

It makes the behavour consistent with the rest of the remote protocol.

The additional round trip is acceptable since the objective is to
implement a primative but (relativly) reliable console.  The objective
is not to implement a high speed data link.

It is possible to implement this in the existing GDB without significant
change.


Input:

For input, GDB would first get the targets attention (<BREAK>) then pass
down the input and finally resume the target vis:

	-> c (continue)
	<BREAK>
	<- T<sigint> (stop)
	-> i<input>
	<- OK
	-> c (continue)
	.....
	<- T.... (stop)

A refinement might see:

	-> c (continue)
	<BREAK>
	<- T<sigint> (stop)
	-> c<input> (continue with input)
	....
	<- T.... (stop)

Pragmatics:

It is slow, oops!  The objective is to implement a functional console,
not a fast console :-)

The interaction is consistent with the rest of the remote protocol - GDB
initiates the transaction.

I think it is possible to modify an existing GDB so that it will behave
this way.  It would probably rely on ``remote *async'' as remote.c would
need to block on both the console and the target.

Unlike other implementations this doesn't involve making the protocol
asynchronous.  Consequently, it should keep the target simpler.

Flow control is a target problem.  That data gets sent across, ready or
not :-)

	thoughts,
		Andrew

Re: gdb/remote - I/O

[Mark Salter]

>>>>> Andrew Cagney writes:

> Input:

> For input, GDB would first get the targets attention (<BREAK>) then pass
> down the input and finally resume the target vis:

-> c (continue)
> 	<BREAK>
> 	<- T<sigint> (stop)
-> i<input>
> 	<- OK
-> c (continue)
> 	.....
> 	<- T.... (stop)

> A refinement might see:

-> c (continue)
> 	<BREAK>
> 	<- T<sigint> (stop)
-> c<input> (continue with input)
> 	....
> 	<- T.... (stop)


Andrew,

From a target-side perspective, I'd like to see this as something like:

-> c (continue)
> 	<- T<sigint> (1)
-> i<input>
> 	<- OK
-> c (continue)
> 	.....

(1) Also extended somehow to include indication that target wants
    input and the max size of the input desired.

This eliminates the need for interrupt/Ctrl-C support in the stub.
I've certainly written stubs for boards that didn't have interrupts
on the debug channel and boards which used an NMI button on the board
for that purpose.

It also explicitly tells gdb whether or not the stub supports input
and provides some flow control by having the target tell gdb how
much input it can handle.

Finally, for stubs which do support input, not all apps will want
to use that mechanism and pushing data from the gdb side would
be disruptive for such apps.

--Mark

Re: gdb/remote - I/O

[Fernando Nasser]

Andrew Cagney wrote:
> 
> Fernando Nasser wrote:
> >
> > I guess Mark found a way to preserve the Request-Response nature of the
> > protocol while processing input without the need of an interrupt.
> >
> > When the target program issues a read from the console, the stub should
> > stop it and send a "T" packet with  SIGTTIN (read on terminal by
> > background process).
> >
> > This reflects what really happens.  The application will probably issue
> > a prompt ("O" packets) and then will need input and will have to halt
> > and wait for it.
> 
> I don't think trying to overload SIGTTIN is correct.  A remote UNIX
> process could get that for reasons other than needing to get input from
> GDB>
> 

It is not "overloading".  The meaning of SIGTTIN is _exactly_ a request
for read from the terminal from a process that does not have immediate
access to the terminal (being in the background is the native version of
this situation).  It is used to tell whoever (if someone) can help this
program to have the input it needs.  In this case it is GDB as it is
acting as it has the "console" for that program.




-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: gdb/remote - I/O

[J.T. Conklin]

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> The existing remote protocol doesn't support input vis: GDB ->
Andrew> target (ignoring the ``target cisco'' hack that just sends raw
Andrew> characters).  I think the current semantics for output are
Andrew> also weak and I'd like to change them.  In the below I'll try
Andrew> to sketch out the basic idea.

Truth be told, I've never used GDB's output packet.  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.  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.

Andrew> Where <BREAK> is the CNTRL-C character but could be some other
Andrew> out-of-band character.  

At present, remote_stop() is implemented, depending on the value of
the remote_break variable, by either a CNTRL-C or a serial break.
Both suffer from a lack of acknowledgement from the target.  What 
are your feelings toward a real stop packet?

Andrew> Appart from the ``O'' (output) packet, the target never
Andrew> initiates anything.

Not that it matters much, but doesn't the cisco variant send a packet
to indicate section offsets?

Are there any other asynchronous events that we might want to be
informed about that don't require the target to be stopped?  Mapping
and unmapping shared libraries?  Thread creation, deletion, or
switching?

Andrew> I'd like to change the protocol so that the output mechanism is
Andrew> synchronous.  That is, instead of:
Andrew>
Andrew>         -> c (continue)
Andrew> 	<- O....  (hex output)
Andrew> 	<- O....  (more hex output)
Andrew> 	<- T... (stop)
Andrew>
Andrew> The output mechanism is treated like any other continue response.  That
Andrew> is, it halts the target and waits for further input vis:
Andrew>
Andrew>         -> c (continue)
Andrew> 	<- o<output> (implied halt)
Andrew>         -> c (continue)
Andrew> 	<- o<more-output> (implied halt)
Andrew>         -> c (continue)
Andrew> 	<- T... (stop)

If we're going to change the protocol, why not make it something
richer than a single stream?  In fact, the i/o protocol doesn't
have to be part of the remote protocol per se, but the protocol
could define a mechanism for tunneling packets through from GDB
to the target and vice versa.

Andrew> It makes the behavour consistent with the rest of the remote
Andrew> protocol.

Yes.  But it does it by shoehorning what is an asynchronous event into
a synchronous framework.  I'm not sure it is desirable.

Andrew> The additional round trip is acceptable since the objective is
Andrew> to implement a primative but (relativly) reliable console.
Andrew> The objective is not to implement a high speed data link.

If it's only a console, please explain why this is valuable in the
real world (as opposed to a toy/trade-show booth demo).  If it's
something better, the latency is going to kill you.

Andrew> It is possible to implement this in the existing GDB without
Andrew> significant change.

Agreed.


Andrew> Input:

Andrew> For input, GDB would first get the targets attention (<BREAK>)
Andrew> then pass down the input and finally resume the target vis:
Andrew>
Andrew>         -> c (continue)
Andrew> 	<BREAK>
Andrew> 	<- T<sigint> (stop)
Andrew>         -> i<input>
Andrew> 	<- OK
Andrew>         -> c (continue)
Andrew> 	.....
Andrew> 	<- T.... (stop)
Andrew>
Andrew> A refinement might see:
Andrew>
Andrew>         -> c (continue)
Andrew> 	<BREAK>
Andrew> 	<- T<sigint> (stop)
Andrew>         -> c<input> (continue with input)
Andrew> 	....
Andrew> 	<- T.... (stop)

Andrew> The interaction is consistent with the rest of the remote
Andrew> protocol - GDB initiates the transaction.

Andrew> I think it is possible to modify an existing GDB so that it
Andrew> will behave this way.  It would probably rely on ``remote
Andrew> *async'' as remote.c would need to block on both the console
Andrew> and the target.

Andrew> Unlike other implementations this doesn't involve making the
Andrew> protocol asynchronous.  Consequently, it should keep the
Andrew> target simpler.

I think you overestimate the difficulty of making a asynchronous debug
agent.

Andrew> Flow control is a target problem.  That data gets sent across,
Andrew> ready or not :-)

I think discounts the problem too easily.  If the target is stopped,
it can't juggle or empty buffers to read in the new data, it also
can't send anything up the output channel to throttle the input.  In
effect, this requires the agent to be deeply entertwined with target
i/o.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: gdb/remote - I/O

[Mark Salter]

>>>>> Andrew Cagney writes:

> Mark Salter wrote:
>> Andrew,
>> 
>> >From a target-side perspective, I'd like to see this as something like:
>> 
-> c (continue)
>> >       <- T<sigint> (1)
-> i<input>
>> >       <- OK
-> c (continue)
>> >       .....
>> 
>> (1) Also extended somehow to include indication that target wants
>> input and the max size of the input desired.

> Wants or is able to accept input?

It could be both if needed.

> What should GDB do if there is no input available?

Continue the target. The target can repeat until it gets what it
needs.

The flip side of this is what to do if input is available, but
the target doesn't ask for it because it stopped for some other
reason.

>> This eliminates the need for interrupt/Ctrl-C support in the stub.
>> I've certainly written stubs for boards that didn't have interrupts
>> on the debug channel and boards which used an NMI button on the board
>> for that purpose.

> Good point.

>> It also explicitly tells gdb whether or not the stub supports input
>> and provides some flow control by having the target tell gdb how
>> much input it can handle.
>> 
>> Finally, for stubs which do support input, not all apps will want
>> to use that mechanism and pushing data from the gdb side would
>> be disruptive for such apps.

> So you're suggesting a polling mechanism?

Yes. The main reasons are (in no particular order):

  o Eliminate requirement for interrupts on the debug channel.

  o Prevent unnecessary interruptions when target doesn't want input.

  o Prevent buffer overflow on the target side.

I guess the first two are closely related.

--Mark

Re: gdb/remote - I/O

[Andrew Cagney]

> It is not "overloading".  The meaning of SIGTTIN is _exactly_ a request
> for read from the terminal from a process that does not have immediate
> access to the terminal (being in the background is the native version of
> this situation).  It is used to tell whoever (if someone) can help this
> program to have the input it needs.  In this case it is GDB as it is
> acting as it has the "console" for that program.

Remember, GDB doesn't necessarily own the terminal that the user is
trying to get input/output through.  The process could be directly
attached to a real tty/pty and that could be separatly be triggering the
SIGTTIN.

	Andrew

Re: gdb/remote - I/O

[Andrew Cagney]

Fernando Nasser wrote:
> 
> I guess Mark found a way to preserve the Request-Response nature of the
> protocol while processing input without the need of an interrupt.
> 
> When the target program issues a read from the console, the stub should
> stop it and send a "T" packet with  SIGTTIN (read on terminal by
> background process).
> 
> This reflects what really happens.  The application will probably issue
> a prompt ("O" packets) and then will need input and will have to halt
> and wait for it.

I don't think trying to overload SIGTTIN is correct.  A remote UNIX
process could get that for reasons other than needing to get input from
GDB>

	Andrew

Re: gdb/remote - I/O

[Frank Ch. Eigler]

jtc wrote:

: [...]
: Truth be told, I've never used GDB's output packet.  

I wonder if you're in a minority!


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


: [...]
: At present, remote_stop() is implemented, depending on the value of
: the remote_break variable, by either a CNTRL-C or a serial break.
: Both suffer from a lack of acknowledgement from the target.  [...]

The lack of a timely response (S/T packet) is an implicit NAK.


: If it's only a console, please explain why this is valuable in the
: real world (as opposed to a toy/trade-show booth demo).  If it's
: something better, the latency is going to kill you.

It's "real world" useful for
- test suites
- fast targets (eg. simulators)


: Andrew> Flow control is a target problem.  That data gets sent across,
: Andrew> ready or not :-)
: 
: I think discounts the problem too easily.  [...]  In effect, this
: requires the agent to be deeply entertwined with target i/o.

That's true, though some degree of intertwining was always involved in
supporting ordinary output packets.  FWIW, I like Fernando's idea of
signalling blocking reads by target stops, i.e., a "pull" model for
input.  It would reduce the need for flow control.


- FChE

Re: gdb/remote - I/O

[Fernando Nasser]

I guess Mark found a way to preserve the Request-Response nature of the
protocol while processing input without the need of an interrupt.

When the target program issues a read from the console, the stub should
stop it and send a "T" packet with  SIGTTIN (read on terminal by
background process).

This reflects what really happens.  The application will probably issue
a prompt ("O" packets) and then will need input and will have to halt
and wait for it.

However, this now puts GDB in an "inferior input" state, as state that
we did not have before). At what level will this be handled?

There are several details that have to be sorted out as well, like if
the "i" packet does not have all the input needed by the read to
continue what should the target do?  Maybe issue another "T<SIGTTIN>"
until it gets all the data it needs.  On the other extreme the user may
have typed ahead.  We can just have the stub discard those (but if we
have echoed the characters typed on the GDB console this can be
confusing).

 
-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: gdb/remote - I/O

[Andrew Cagney]

Mark Salter wrote:

> Andrew,
> 
> >From a target-side perspective, I'd like to see this as something like:
> 
> -> c (continue)
> >       <- T<sigint> (1)
> -> i<input>
> >       <- OK
> -> c (continue)
> >       .....
> 
> (1) Also extended somehow to include indication that target wants
>     input and the max size of the input desired.

Wants or is able to accept input?
What should GDB do if there is no input available?

> This eliminates the need for interrupt/Ctrl-C support in the stub.
> I've certainly written stubs for boards that didn't have interrupts
> on the debug channel and boards which used an NMI button on the board
> for that purpose.

Good point.

> It also explicitly tells gdb whether or not the stub supports input
> and provides some flow control by having the target tell gdb how
> much input it can handle.
> 
> Finally, for stubs which do support input, not all apps will want
> to use that mechanism and pushing data from the gdb side would
> be disruptive for such apps.

So you're suggesting a polling mechanism?

	Andrew

Re: gdb/remote - I/O

[Grant Edwards]

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

Re: gdb/remote - I/O

[Todd Whitesel]

> However, this now puts GDB in an "inferior input" state, as state that
> we did not have before). At what level will this be handled?
> 
> There are several details that have to be sorted out as well, like if
> the "i" packet does not have all the input needed by the read to
> continue what should the target do?  Maybe issue another "T<SIGTTIN>"
> until it gets all the data it needs.  On the other extreme the user may
> have typed ahead.  We can just have the stub discard those (but if we
> have echoed the characters typed on the GDB console this can be
> confusing).

I prefer the implementation where target I/O is treated like a general
syscall request, which always blocks on the host. After all, it's really
for debugging and bootstrapping, not production -- and you gain a lot of
flexibility by doing it this way.

On the target, a syscall acts just like a breakpoint except that some
extra "I'm a syscall!" information is sent up too. For example, the
syscall number and the first three argument registers, which covers
all of your basic syscalls.

The target then just sits and waits to be manipulated with register/memory
commands, and eventually gets a command sequence telling it to write the
return register and 'errno flag' register and to continue.

On the host, a target that stops on a syscall gets processed through logic
which feels somewhat like the "should we continue stepping or not?" paths
in The Code Formerly Known As WaitForInferior. The host translates the
syscall to native bit-flags and such and attempts to execute it, including
simulated I/O (you need some minimal buffering here, nothing complicated).

If the requested syscall completes immediately, great. Diddle the target
and resume it. But if it doesn't, then you put the inferior into a state
which says "blocked on I/O" that is generally equivalent to "running" but
tells the event loop to keep checking to see if the target I/O can be
completed. Presumably this involves some combination of select/poll,
non-blocking read's, interaction with GUI's, etc.

The main things to keep straight are that the target PC has to remain at
the syscall instruction itself UNTIL the syscall is completed. This allows
you to process a user-level stop request by simply dropping the syscall and
declaring the target stopped. If the target is then continued at the same
PC, the syscall is simply re-executed.

Todd Whitesel
toddpw @ best.com

Re: gdb/remote - I/O

[Andrew Cagney]

Todd Whitesel wrote:

> I prefer the implementation where target I/O is treated like a general
> syscall request, which always blocks on the host. After all, it's really
> for debugging and bootstrapping, not production -- and you gain a lot of
> flexibility by doing it this way.

syscall?  Ah, you're thinking of UNIX :-)

> On the target, a syscall acts just like a breakpoint except that some
> extra "I'm a syscall!" information is sent up too. For example, the
> syscall number and the first three argument registers, which covers
> all of your basic syscalls.

> The target then just sits and waits to be manipulated with register/memory
> commands, and eventually gets a command sequence telling it to write the
> return register and 'errno flag' register and to continue.
> 
> On the host, a target that stops on a syscall gets processed through logic
> which feels somewhat like the "should we continue stepping or not?" paths
> in The Code Formerly Known As WaitForInferior. The host translates the
> syscall to native bit-flags and such and attempts to execute it, including
> simulated I/O (you need some minimal buffering here, nothing complicated).

I was waiting for someone to head down that path :-)

While a ``really cool feature'' I think, like the other proposal to make
things truely bi-directional it is getting away from the current
protocol's principal objective - to be as simple as possible.

I don't think a ``syscall'' mechanism would need any protocol changes
(just a minor reimplementation of GDB's target stack ;-)  I'd expect
something like a new target layer that would set a breakpoint on
syscall() and then intercept any thread-stopped event for that
breakpoint.  The layer would then manipulate the target and resume it.

I think the emphasis here should be on identifying just sufficient
functionality to provide the primative console.  Mark's point about the
target not having a break mechanism is the key - my original proposal
was flawed since it assume that GDB could directly interrupt the target.

	Andrew

Re: gdb/remote - I/O

[Andrew Cagney]

"J.T. Conklin" wrote:
> 
> >>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
> Andrew> The existing remote protocol doesn't support input vis: GDB ->
> Andrew> target (ignoring the ``target cisco'' hack that just sends raw
> Andrew> characters).  I think the current semantics for output are
> Andrew> also weak and I'd like to change them.  In the below I'll try
> Andrew> to sketch out the basic idea.
> 
> Truth be told, I've never used GDB's output packet.  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.  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.

As Frank noted, the testsuite exploits it.

> Andrew> Where <BREAK> is the CNTRL-C character but could be some other
> Andrew> out-of-band character.
> 
> At present, remote_stop() is implemented, depending on the value of
> the remote_break variable, by either a CNTRL-C or a serial break.
> Both suffer from a lack of acknowledgement from the target.  What
> are your feelings toward a real stop packet?

I suspect we're stuck with the situtation that a ``stop'' or ``break''
should be out-of-band.  I'm actually suprised that no one has suggested
sending a real BREAK instead of that cntrl-c.

> Andrew> Appart from the ``O'' (output) packet, the target never
> Andrew> initiates anything.
> 
> Not that it matters much, but doesn't the cisco variant send a packet
> to indicate section offsets?

It is part of their custom stop packet (N).
It turns out that some of the more exotic PDA OS's could also benefit
from a section offsets packet.

> Are there any other asynchronous events that we might want to be
> informed about that don't require the target to be stopped?  Mapping
> and unmapping shared libraries?  Thread creation, deletion, or
> switching?

That is the thing.  While it would be nice if the remote target didn't
stop, in reality, it does.  For any of these events to be passed back to
GDB, the target has to stop for at least a short period of time.

> Andrew>         -> c (continue)
> Andrew>         <- o<output> (implied halt)
> Andrew>         -> c (continue)
> Andrew>         <- o<more-output> (implied halt)
> Andrew>         -> c (continue)
> Andrew>         <- T... (stop)
> 
> If we're going to change the protocol, why not make it something
> richer than a single stream?  In fact, the i/o protocol doesn't
> have to be part of the remote protocol per se, but the protocol
> could define a mechanism for tunneling packets through from GDB
> to the target and vice versa.

These are both good ideas:

	o	separate the GDB remote protocol
		from its transport layer

	o	implement a new transport
		that supports multiple channels

however that is separate to changing the way the current remote protocol
works.

> Andrew> It makes the behavour consistent with the rest of the remote
> Andrew> protocol.
> 
> Yes.  But it does it by shoehorning what is an asynchronous event into
> a synchronous framework.  I'm not sure it is desirable.

At some level or another, these events need to be synchronized.  For the
target to send console output back through to GDB it will need to
synchronize its self with with the debug server.

> Andrew> The additional round trip is acceptable since the objective is
> Andrew> to implement a primative but (relativly) reliable console.
> Andrew> The objective is not to implement a high speed data link.
> 
> If it's only a console, please explain why this is valuable in the
> real world (as opposed to a toy/trade-show booth demo).  If it's
> something better, the latency is going to kill you.

See Mark and Frank's comments about debugging and testing.
(I actually suspect it would never be used in a toy/trade-show demo - a
demo printing ``hello world'' would just be laughed at by marketing :-)

> Andrew> Input:

> Andrew> Unlike other implementations this doesn't involve making the
> Andrew> protocol asynchronous.  Consequently, it should keep the
> Andrew> target simpler.
> 
> I think you overestimate the difficulty of making a asynchronous debug
> agent.

Actually, I underestimated!  See Mark's comment about no interrupt and
no timer.  On some targets it just ain't possible.

> Andrew> Flow control is a target problem.  That data gets sent across,
> Andrew> ready or not :-)
> 
> I think discounts the problem too easily.  If the target is stopped,
> it can't juggle or empty buffers to read in the new data, it also
> can't send anything up the output channel to throttle the input.  In
> effect, this requires the agent to be deeply entertwined with target
> i/o.

Yes, this was wrong.  Marks's pointed out that the target should poll.

	Andrew

Re: gdb/remote - I/O

[Andrew Cagney]

Just an additional datapoint on this.

The qRcmd packet (my fault) and the tracepoint packets (I've been
reading C code) both use the existing ``O'' packet to send additional
output back from the target during a query.

The obvious question is where exactly that ``O'' packet is ment to be
going - gdb_stdtarg, gdb_stdlog or gdb_stdout.  If it is gdb_stdout and
there is a pager things can get really complicated.

	Andrew

Re: gdb/remote - I/O

[Fernando Nasser]

Andrew Cagney wrote:
> 
> Just an additional datapoint on this.
> 
> The qRcmd packet (my fault) and the tracepoint packets (I've been
> reading C code) both use the existing ``O'' packet to send additional
> output back from the target during a query.
> 
> The obvious question is where exactly that ``O'' packet is ment to be
> going - gdb_stdtarg, gdb_stdlog or gdb_stdout.  If it is gdb_stdout and
> there is a pager things can get really complicated.
> 

We do have two different kinds of output coming from the target: output
produced by the os/monitor/stub or whatever we are talking to and the
output from the application (little bit of semi-hosting).

Fortunately for us, they happen at different times.  When the program is
running (after run or step) the output can be assumed to be from the
program and should go to gdb_stdtarg.  When the program is not running
the output can only be from the controlling software, and we can send it
to gdb_stdout.


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: gdb/remote - I/O

[J.T. Conklin]

>>>>> "Fernando" == Fernando Nasser <fnasser@redhat.com> writes:
Fernando> We do have two different kinds of output coming from the
Fernando> target: output produced by the os/monitor/stub or whatever
Fernando> we are talking to and the output from the application
Fernando> (little bit of semi-hosting).
Fernando>
Fernando> Fortunately for us, they happen at different times.  When
Fernando> the program is running (after run or step) the output can be
Fernando> assumed to be from the program and should go to gdb_stdtarg.
Fernando> When the program is not running the output can only be from
Fernando> the controlling software, and we can send it to gdb_stdout.

I've been thinking about the proposed changes to the remote protocol
since they were first brought up.  I've been trying to come to terms
with an issue myself before I put it up for discussion in a coherent
manner, but since I'm not making much progress on my own I thought I'd
better better share what I've got.

Question: Does the remote protocol support systems where other threads
continue to execute when one being debugged is halted.  This is a hard
question to answer, since the existing implementation of both GDB and
the debug agents (stubs, gdbserver, and I suppose libremote (although
I've never seen it)) assume the target completely stops.  But does the
protocol itself allow this?  From what I can tell, it can.  If it does
not, it almost does --- especially when you consider how loosely some 
of the commands are defined.

The proposals wrt. I/O seem to require the target to halt for I/O,
which precludes enhancing GDB and the debug agents to take full
advantage of the remote protocol.  I ask whether or not this is 
desirable?

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: gdb/remote - I/O

[Frank Ch. Eigler]

jtc wrote:

: [...]
: Question: Does the remote protocol support systems where other threads
: continue to execute when one being debugged is halted.  [...] But does 
: the protocol itself allow this?  From what I can tell, it can.  If it does
: not, it almost does --- especially when you consider how loosely some 
: of the commands are defined.

While the wire protocol is indeed rather loose, the process model
assumed by the dominant party (gdb) should be respected.  I would
ascribe looseness not to encouraging creative implementations, but to
systemic lack of formality.

If your target requires some mixed halted/running thread states, and
you run into problems with gdb's model, you could consider switching
to a multi-process rather than multi-thread debugging model.


: The proposals wrt. I/O seem to require the target to halt for I/O,
: which precludes enhancing GDB and the debug agents to take full
: advantage of the remote protocol.  I ask whether or not this is 
: desirable?

Is there anything special about I/O in this way?  If your unusual
target, when responding to a ^C/break from gdb, decides to stop just
one thread, it could do the same thing for I/O.  It could suspend the
output-causing thread; it could suspend any old thread for enqueueing
input.


- FChE

Re: gdb/remote - I/O

[J.T. Conklin]

>>>>> "Frank" == Frank Ch Eigler <fche@redhat.com> writes:

Frank> jtc wrote:
Frank> : Question: Does the remote protocol support systems where
Frank> : other threads continue to execute when one being debugged is
Frank> : halted.  [...] But does the protocol itself allow this?  From
Frank> : what I can tell, it can.  If it does not, it almost does ---
Frank> : especially when you consider how loosely some of the commands
Frank> : are defined.

Frank> While the wire protocol is indeed rather loose, the process
Frank> model assumed by the dominant party (gdb) should be respected.
Frank> I would ascribe looseness not to encouraging creative
Frank> implementations, but to systemic lack of formality.

Frank> If your target requires some mixed halted/running thread
Frank> states, and you run into problems with gdb's model, you could
Frank> consider switching to a multi-process rather than multi-thread
Frank> debugging model.

The reason I asked is that from time to time over the last few years,
there has been talk of enhancing GDB to use a more complicated model
where systems with multiple (possibly heterogenous) processors, each
with multiple processes, each with multiple threads could be debugged.
If this is still the goal, we need to consider whether each decision
we make takes us closer or precludes us from reaching the goal.

Frank> : The proposals wrt. I/O seem to require the target to halt for I/O,
Frank> : which precludes enhancing GDB and the debug agents to take full
Frank> : advantage of the remote protocol.  I ask whether or not this is 
Frank> : desirable?

Frank> Is there anything special about I/O in this way?  If your
Frank> unusual target, when responding to a ^C/break from gdb, decides
Frank> to stop just one thread, it could do the same thing for I/O.
Frank> It could suspend the output-causing thread; it could suspend
Frank> any old thread for enqueueing input.

With this model, you might be connected to the target (thus be able to
handle I/O) but not attached to any one thread.  I've debugged vxWorks
targets this way, where the system is free running and all I can do is
memory reads and writes.  This loses if I/O can only be handled while
waiting for an inferior thread/process.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: gdb/remote - I/O

[Andrew Cagney]

Hello,

Given the recent discussion on the qSymbol packet and a comment that the 
target should be able to initiate such an interaction, I'd like to 
propose the following as a possible interaction.


	<target running>

	<- T00;qSymbol;qIn;
.
		i.e. the target can stop and
		drop a big hint that it would
		like to be probed for the given
		packet - here qSymbol and qIn
		The target has also bundled up
		some output data.

	-> qIn;<bytes-of-input>

		Something goes in the .....
		it might be bytes of input
		it might be something else

	<- "" packet not recognized
	<- "OK" nothing at present


	-> qSymbol....
	<- ....
	-> qSumbol....
	<- ....

	-> C
		The exchange is finished continue
		the target.

	<target resumes execution>

The main point is that this allows the target to initiate an interaction 
by pigybacking what they want on a dummy ``T'' packet while at the same 
time leaving the host in control - all interactions still being host 
initiated.

	Andrew

Re: gdb/remote - I/O

[Andrew Cagney]

> This is what the ChorusOS DebugAgent is doing.  This has some advantages
> (when you debug you can stop easily at the output/input), but the big draw
> back is that this is very slow.  A second drawback is that this is highly
> intrusive for the target program (here, this will depends on the implementation
> of the gdbserver/serial line driver on the target).

Good grief!  Perhaphs the idea isn't as tacky as I first thought :-) 
Yes, it has all of those problems.

> What is interesting is that we often think in implementing the non-intrusive
> output (ie, no implied halt).  So, I suggest this kind of behavior become
> an option.

It gets complicated.  Consider GDB's existing ``O'' packet as an example
of what to not do.  Unless the target is doing a synchronous call into
the monitor to perform the transfer (and hence intruding), the
implementation is most likely broken. GDB could send a <break> slam bang
in the middle of that ``O'' packet transfer and hence, have that request
lost.

Perhaps the lack of performance should be documented as a ``feature''
:-)  It would encourage people with console performance problems to
re-implement their console using a separate transport.

Thanks for this feedback,

	Andrew

Re: gdb/remote - I/O

[Stephane Carrez]

Hi Andrew,

>Hello,
>
>The existing remote protocol doesn't support input vis: GDB -> target
>(ignoring the ``target cisco'' hack that just sends raw characters).  I
>think the current semantics for output are also weak and I'd like to
>change them.  In the below I'll try to sketch out the basic idea.

Yes, Input/output is not handled in a good way for remote targets.
This is true also for monitors (:-

For ChorusOS I solved that by introducing our console management within
the GDB ChorusOS remote target.  If we could have something more generic,
or re-usable at target/monitor level, this would help.


> [...]
>
>
>The output mechanism is treated like any other continue response.  That
>is, it halts the target and waits for further input vis:
>
>	-> c (continue)
>	<- o<output> (implied halt)
>	-> c (continue)
>	<- o<more-output> (implied halt)
>	-> c (continue)
>	<- T... (stop)
>
>
>Pragmatics:
>
>It makes the behavour consistent with the rest of the remote protocol.
>
>The additional round trip is acceptable since the objective is to
>implement a primative but (relativly) reliable console.  The objective
>is not to implement a high speed data link.
>
>It is possible to implement this in the existing GDB without significant
>change.
>

This is what the ChorusOS DebugAgent is doing.  This has some advantages
(when you debug you can stop easily at the output/input), but the big draw
back is that this is very slow.  A second drawback is that this is highly
intrusive for the target program (here, this will depends on the implementation
of the gdbserver/serial line driver on the target).


What is interesting is that we often think in implementing the non-intrusive
output (ie, no implied halt).  So, I suggest this kind of behavior become
an option.

>
>Input:
>
>For input, GDB would first get the targets attention (<BREAK>) then pass
>down the input and finally resume the target vis:
>
>	-> c (continue)
>	<BREAK>
>	<- T<sigint> (stop)
>	-> i<input>
>	<- OK
>	-> c (continue)
>	.....
>	<- T.... (stop)
>
>A refinement might see:
>
>	-> c (continue)
>	<BREAK>
>	<- T<sigint> (stop)
>	-> c<input> (continue with input)
>	....
>	<- T.... (stop)
>
>Pragmatics:
>
>It is slow, oops!  The objective is to implement a functional console,
>not a fast console :-)
>
>The interaction is consistent with the rest of the remote protocol - GDB
>initiates the transaction.
>
>I think it is possible to modify an existing GDB so that it will behave
>this way.  It would probably rely on ``remote *async'' as remote.c would
>need to block on both the console and the target.
>
>Unlike other implementations this doesn't involve making the protocol
>asynchronous.  Consequently, it should keep the target simpler.
>
>Flow control is a target problem.  That data gets sent across, ready or
>not :-)
>
>	thoughts,
>		Andrew

Agree.  This is how ChorusOS DebugAgent/DebugServer cooperate for the input.

In this direction, the performance is less important.  In general you
expect more outputs than inputs.

Cheers,
	Stephane

-	-	-	-	-	-	-	-	-	-
Stephane |Sun Microsystems			|
 Carrez	 |Network Service Provider Division	| http://www.sun.com
	 |6 avenue Gustave Eiffel		|
	 |F-78182, St-Quentin-en-Yvelines-Cedex |

email: Stephane.Carrez@France.Sun.COM