AW: Problems with run tests on a i386 platform

AW: Problems with run tests on a i386 platform

[Hansjörg Petriffer]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 6090 bytes --]

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 <mailing@ciudaderotica.com.ar>
To: <gdb@sourceware.cygnus.com>
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 <eliz@is.elta.co.il>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: GDB Discussion <gdb@sources.redhat.com>
Subject: Re: ``trace frames'' vs ``frames'' vs ``trace snaps''
Date: Sun, 25 Mar 2001 23:25:00 -0000
Message-id: <Pine.SUN.3.91.1010326092331.4400D-100000@is>
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 <Stephane.Carrez@Sun.COM>
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<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