From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hansjörg Petriffer To: 'Keith Seitz' , "'gdb@sourceware.cygnus.com'" Subject: AW: Problems with run tests on a i386 platform Date: Sun, 25 Mar 2001 22:57:00 -0000 Message-id: X-SW-Source: 2001-03/msg00277.html Sorry now is working. It was a problem with the com1. It seems for me that win 2k does something with the first com port Thank for your help! -----Ursprüngliche Nachricht----- Von: Keith Seitz [ mailto:keiths@cygnus.com ] Gesendet: Freitag, 23. März 2001 18:23 An: Hansjörg Petriffer; 'gdb@sourceware.cygnus.com' Betreff: Re: Problems with run tests on a i386 platform On Fri, 23 Mar 2001, Keith Seitz wrote: > > Ignoring packet error, continuing... > > Ignoring packet error, continuing... > > Ignoring packet error, continuing... > > Couldn't establish connection to remote target > > Malformed response to offset query, timeout Okay, scratch that. You're timing out. There is something wrong with your serial connection. Try using (or not using) a null modem adapter, different serial ports. Try setting the baudrate to 9600, etc. Keith >From mailing@ciudaderotica.com.ar Sun Mar 25 23:11:00 2001 From: Ciudad Erotica To: Subject: Nuevo Sitio - Sensual, muy sensual... Date: Sun, 25 Mar 2001 23:11:00 -0000 Message-id: <00c781004071a31MAIL2@mail2.radar.com.ar> X-SW-Source: 2001-03/msg00278.html Content-length: 591 www.ciudad-erotica.com.ar Ciudad Erotica ------------------------------------------------------------------------------------------ Las mujeres escorts mas hermosas de Bs.As. El mejor Sex Shop de Argentina a su alcance, con regalos permanentes, promociones y descuentos increibles. No deje de visitarnos!! www.ciudad-erotica.com.ar __________________________________________________________________________________ Este e-mail lo recibira por unica vez, por lo tanto no es necesario unsuscribirce. Disculpe las molestias El equipo de Ciudad Erotica >From eliz@is.elta.co.il Sun Mar 25 23:25:00 2001 From: Eli Zaretskii To: Andrew Cagney Cc: GDB Discussion Subject: Re: ``trace frames'' vs ``frames'' vs ``trace snaps'' Date: Sun, 25 Mar 2001 23:25:00 -0000 Message-id: References: <3ABE56C2.2AE6CB0B@cygnus.com> X-SW-Source: 2001-03/msg00279.html Content-length: 267 On Sun, 25 Mar 2001, Andrew Cagney wrote: > I'd like address this by replacing [movie] frame with something like > ``snap'', ``snapshot'', slide, ???? While reading your message, I was about to suggest ``snapshot'', even before I saw it among your suggestions. ;-) >From Stephane.Carrez@Sun.COM Mon Mar 26 01:02:00 2001 From: Stephane Carrez To: ac131313@cygnus.com Cc: gdb@sources.redhat.com Subject: Re: gdb/remote - I/O Date: Mon, 26 Mar 2001 01:02:00 -0000 Message-id: <200103260902.LAA00204@sunchorus.France.Sun.COM> X-SW-Source: 2001-03/msg00280.html Content-length: 3265 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 (implied halt) > -> c (continue) > <- o (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 () then pass >down the input and finally resume the target vis: > > -> c (continue) > > <- T (stop) > -> i > <- OK > -> c (continue) > ..... > <- T.... (stop) > >A refinement might see: > > -> c (continue) > > <- T (stop) > -> c (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