Re: gdb/remote - I/O

[Fernando Nasser <fnasser@redhat.com>]

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
From jtc@redback.com Thu Mar 29 16:27:00 2001
From: jtc@redback.com (J.T. Conklin)
To: Andrew Cagney <ac131313@cygnus.com>
Cc: GDB Discussion <gdb@sources.redhat.com>
Subject: Re: gdb/remote - I/O
Date: Thu, 29 Mar 2001 16:27:00 -0000
Message-id: <5mhf0fov3q.fsf@jtc.redback.com>
References: <3ABBDDE4.7C22709D@cygnus.com>
X-SW-Source: 2001-03/msg00303.html
Content-length: 4742

>>>>> "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
From ac131313@cygnus.com Thu Mar 29 16:27:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Stephane Carrez <Stephane.Carrez@Sun.COM>
Cc: gdb@sources.redhat.com
Subject: Re: gdb/remote - I/O
Date: Thu, 29 Mar 2001 16:27:00 -0000
Message-id: <3ABF62C1.40CE4764@cygnus.com>
References: <200103260902.LAA00204@sunchorus.France.Sun.COM>
X-SW-Source: 2001-03/msg00286.html
Content-length: 1229

> 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
From cgf@redhat.com Thu Mar 29 16:27:00 2001
From: Christopher Faylor <cgf@redhat.com>
To: "'gdb@sources.redhat.com'" <gdb@sources.redhat.com>
Subject: Re: missing headerfile windows.h
Date: Thu, 29 Mar 2001 16:27:00 -0000
Message-id: <20010328144848.J32159@redhat.com>
References: <10DFD823BCD8D311ACCD00805FE950B6343EFD@mail.reterm.se> <3AC21A00.1001BB9@cygnus.com>
X-SW-Source: 2001-03/msg00312.html
Content-length: 885

On Wed, Mar 28, 2001 at 12:06:08PM -0500, Andrew Cagney wrote:
>Odd Lindahl wrote:
>> 
>> Hi,
>> 
>> I'm trying to compile gdb 5.0 and or insight 5.0 in a cygnus 1.18
>> environment
>> with newlib 1.9.0 and binutils 2.10.1 and gcc 2.95.2 as a cross compiler
>> with target=arm-elf.
>> 
>> I've successfully compiled binutils,newlib,gcc and when I do:
>> 
>> $mkdir -p /tmp/build/gdb
>> $cd /tmp/build/gdb
>> $/src/gdb/gdb-5.0/configure --target=arm-elf \
>> >--prefix=/tools \
>> >--exec-prefix=/tools/H-i686-pc-cygwin \
>> >-v 2>&1 | tee configure.out
>
>Try:
>	CC="gcc -mwin32" CXX="g++ -mwin32" /.../confgure .....

Or, upgrade to the latest version of Cygwin gcc, which should fix this
problem.

I have some patches coming for gdb which also correct some WIN32/CYGWIN
misperceptions.  I was surprised to see that gdb had some WIN32 ifdefs
that were just not right for Cygwin.

cgf
From msalter@redhat.com Thu Mar 29 16:27:00 2001
From: Mark Salter <msalter@redhat.com>
To: ac131313@cygnus.com
Cc: gdb@sources.redhat.com
Subject: Re: gdb/remote - I/O
Date: Thu, 29 Mar 2001 16:27:00 -0000
Message-id: <200103261954.f2QJsBg15093@deneb.localdomain>
References: <3ABBDDE4.7C22709D@cygnus.com> <200103261830.f2QIU2614825@deneb.localdomain> <3ABF9077.DFC22AE7@cygnus.com>
X-SW-Source: 2001-03/msg00291.html
Content-length: 1628

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