From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fernando Nasser To: Andrew Cagney Cc: Mark Salter , gdb@sources.redhat.com Subject: Re: gdb/remote - I/O Date: Thu, 29 Mar 2001 16:27:00 -0000 Message-id: <3AC0CBF6.C50C1827@redhat.com> References: <3ABBDDE4.7C22709D@cygnus.com> <200103261830.f2QIU2614825@deneb.localdomain> <3ABF9077.DFC22AE7@cygnus.com> <200103261954.f2QJsBg15093@deneb.localdomain> <3ABFA8D1.DA0D2EAE@redhat.com> <3AC0C9DF.CB1BC2D9@cygnus.com> X-SW-Source: 2001-03/msg00301.html 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 Cc: GDB Discussion 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 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 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 (implied halt) Andrew> -> c (continue) Andrew> <- o (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 () Andrew> then pass down the input and finally resume the target vis: Andrew> Andrew> -> c (continue) Andrew> Andrew> <- T (stop) Andrew> -> i Andrew> <- OK Andrew> -> c (continue) Andrew> ..... Andrew> <- T.... (stop) Andrew> Andrew> A refinement might see: Andrew> Andrew> -> c (continue) Andrew> Andrew> <- T (stop) Andrew> -> c (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 To: Stephane Carrez 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 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 To: "'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 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 (1) -> i >> > <- 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