Re: gdb/remote - I/O

[Andrew Cagney <ac131313@cygnus.com>]

> 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
From RDBrown@mira.net Thu Mar 29 16:27:00 2001
From: RDBrown@mira.net
To: gdb@sources.redhat.com, gdb-patches@sources.redhat.com
Subject: gdb March 2001 archive
Date: Thu, 29 Mar 2001 16:27:00 -0000
Message-id: <E14hrAI-00006p-00@urtur>
X-SW-Source: 2001-03/msg00298.html
Content-length: 1288

The gdb Mar 2001 archive hasn't moved past March 21 - is the mail getting
through or is it just the archive?

What do you want loaded on the testresults page?
gdb/testsuite/gdb.log or gdb/testsuite/gdb.sum?

Building from the 0324 snapshot on alpha-dec-osf4.0e and i586-sco-sysv5uw7.1.0
somewhat required the following patch - which should be done with autoconf.
Both provide NSIG but only if _XOPEN_SOURCE etc are undefined.
(Both using gcc-2.95.2)

On alpha-dec-osf4.0e the link failed missing `in_solib_dynsym_resolve_code'.

/usr/bin/ld:
Unresolved:
in_solib_dynsym_resolve_code
collect2: ld returned 1 exit status

--- expect/exp_trap.c.orig	Tue Mar 27 00:17:00 2001
+++ expect/exp_trap.c	Mon Mar 26 13:18:59 2001
@@ -22,6 +22,12 @@
 #ifndef NSIG
 #ifdef _NSIG
 #define NSIG _NSIG
+#else
+#ifdef __osf__	/* alpha-dec-osf4.0e workaround */
+#define NSIG 49
+#else		/* i586-sco-sysv5uw7.1.0 workaround */
+#define NSIG 35
+#endif
 #endif
 #endif
 
--- expect/exp_command.c.orig	Tue Mar 27 00:17:15 2001
+++ expect/exp_command.c	Mon Mar 26 13:18:50 2001
@@ -53,6 +53,12 @@
 #ifndef NSIG
 #ifdef _NSIG
 #define NSIG _NSIG
+#else
+#ifdef __osf__	/* alpha-dec-osf4.0e workaround */
+#define NSIG 49
+#else		/* i586-sco-sysv5uw7.1.0 workaround */
+#define NSIG 35
+#endif
 #endif
 #endif
 
From ac131313@cygnus.com Thu Mar 29 16:27:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Fernando Nasser <fnasser@redhat.com>
Cc: Mark Salter <msalter@redhat.com>, gdb@sources.redhat.com
Subject: Re: gdb/remote - I/O
Date: Thu, 29 Mar 2001 16:27:00 -0000
Message-id: <3AC0C9DF.CB1BC2D9@cygnus.com>
References: <3ABBDDE4.7C22709D@cygnus.com> <200103261830.f2QIU2614825@deneb.localdomain> <3ABF9077.DFC22AE7@cygnus.com> <200103261954.f2QJsBg15093@deneb.localdomain> <3ABFA8D1.DA0D2EAE@redhat.com>
X-SW-Source: 2001-03/msg00300.html
Content-length: 658

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
From fche@redhat.com Thu Mar 29 16:27:00 2001
From: fche@redhat.com (Frank Ch. Eigler)
To: jtc@redback.com
Cc: Andrew Cagney <cagney@cygnus.com>, GDB Discussion <gdb@sources.redhat.com>
Subject: Re: gdb/remote - I/O
Date: Thu, 29 Mar 2001 16:27:00 -0000
Message-id: <o5snjxvnpk.fsf@touchme.toronto.redhat.com>
References: <3ABBDDE4.7C22709D@cygnus.com> <5mhf0fov3q.fsf@jtc.redback.com>
X-SW-Source: 2001-03/msg00309.html
Content-length: 2008

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
From ac131313@cygnus.com Thu Mar 29 16:27:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Steven Johnson <sjohnson@neurizon.net>
Cc: Fernando Nasser <fnasser@redhat.com>, Steven Johnson <sbjohnson@ozemail.com.au>, gdb@sources.redhat.com
Subject: Re: Register Cache.
Date: Thu, 29 Mar 2001 16:27:00 -0000
Message-id: <3ABFE1FA.22F1C66B@cygnus.com>
References: <8AE4B526B977D411841F00A0CC334020052C28@cuz-exchange.sdesigns.net> <39AC598A.DFAF67E9@ozemail.com.au> <3ABF562F.2144AF18@cygnus.com> <3ABF5DF9.4D630216@redhat.com> <3ABFD062.17EDADAF@neurizon.net>
X-SW-Source: 2001-03/msg00294.html
Content-length: 601

Steven Johnson wrote:

> I have gotten around the issues by invalidating the register cache
> between writes. This is obviously sub-optimal but it works OK.

Very sub-optimal.  Being able to blat register_valid[] is going away :-)

> A better implementation would be to allow a setting on a register by
> register basis that sets how it will be cached by reg-cache.  At the
> time of the original post, this was a fairly major undertaking.
> Regcache currently seems to be undergoing changes that will make
> implementing this easier but for the moment flushing works fine.

I hope it helps.

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

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
From dolson@dotcast.com Thu Mar 29 16:27:00 2001
From: "Dan Olson (Seattle)" <dolson@dotcast.com>
To: "'gdb@sourceware.cygnus.com'" <gdb@sourceware.cygnus.com>
Subject: Hacking gdb and binutils (gas especially)
Date: Thu, 29 Mar 2001 16:27:00 -0000
Message-id: <EC99B1554DB004429CE45256BBEDABD815B07C@DC-SRVR1.dotcast.com>
X-SW-Source: 2001-03/msg00305.html
Content-length: 504

Hi all,

What is the best way to get a matched version of gdb and gas,binutils.  I'm
tweaking BFD and opcodes and want gdb and gas to share the same libs.  Right
now I'm am trying to use binutils-2.10.1 with the gdb-5.0 unique directories
moved in.  Seems to kinda work but some targets I don't care about won't
build (sim/v850 - I see the problem is having libintl linked in).

Is there a better way to get a src tree with both gdb and binutils that all
play together?

--
Dan Olson
dolson@dotcast.com