gdb/remote - I/O

gdb/remote - I/O

[Andrew Cagney]

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.

As way of background, the remote protocol is not symetric.  GDB
initiates everything and then the target (eventually) responds.  For
instance:

	-> g (read registers)

	<- 12345678123456781234567812345678
	   (register bytes in hex)

A target is continued with:

	-> c (continue)

	(time passes)

	<- T....
	   (stop with info)

To halt the target:

	-> c (continue)
	(time passes)
	<BREAK>
	(time passes)
	<- T.... (stop)

Where <BREAK> is the CNTRL-C character but could be some other
out-of-band character.
Appart from the ``O'' (output) packet, the target never initiates
anything.


Output:

I'd like to change the protocol so that the output mechanism is
synchronous.  That is, instead of:

	-> c (continue)
	<- O....  (hex output)
	<- O....  (more hex output)
	<- T... (stop)

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.


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
From tanvir.hassan@tumisoftware.com Fri Mar 23 16:02:00 2001
From: Tanvir Hassan <tanvir.hassan@tumisoftware.com>
To: 'Daniel Berlin' <dan@www.cgsoftware.com>, Tanvir Hassan <tanvir.hassan@tumisoftware.com>
Cc: 'Michael Elizabeth Chastain' <chastain@cygnus.com>, gdb@sourceware.cygnus.com
Subject: RE: using GDB 5 on Solaris 7 with Sun WS5.0
Date: Fri, 23 Mar 2001 16:02:00 -0000
Message-id: <3DD49A5C2322D411B6AE00C00D01611506CD84@HELIOS>
X-SW-Source: 2001-03/msg00261.html
Content-length: 4409

Hmmm.  Can I use a c++filt/dem type program that can take mangled names and
produce demangled names to get around the name mangling problem?

Also, I still cannot debug a program unless I include "-xs".  Is the psymtab
stuff not meant to deal with non "-xs" code?  Or am I stuck using "-xs" to
debug under WS5.0 and GDB on Solaris 7?

-----Original Message-----
From: Daniel Berlin [ mailto:dan@www.cgsoftware.com ]
Sent: Friday, March 23, 2001 2:35 PM
To: Tanvir Hassan
Cc: 'Michael Elizabeth Chastain'; gdb@sourceware.cygnus.com
Subject: RE: using GDB 5 on Solaris 7 with Sun WS5.0




On Fri, 23 Mar 2001, Tanvir Hassan wrote:

> Here's the stuff I get from "man CC" on SunWorkshop 5 C++:
> 
> Note that -compat=5 (which lets me use STL) will set the __cplusplus macro
> to "199711L".  I don't know if that helps in determining which ABI those
> guys are following.  Also, I tried to compile helloworld.cpp with -g and
see
> if the newest snapshot (23/Mar/2001) could debug it without me resorting
to
> -xs and it cannot.  Is there an option or config.h option that I need to
> enable psymtab stuff?
Nope.
It's automagic.

> 
> 
>      -compat[=(4|5)]
>                Sets the compiler to be compatible with 4.0.1,
>                4.1, and 4.2 compilers; or with full 5.0. This
>                option controls the preprocessor __cplusplus
>                macro.
> 
>                The C++ compiler has two principal modes.  One
>                accepts the semantics and language defined by the
>                Annotated C++ Reference Manual (ARM) and used in
>                the 4.2 compiler (the compatibility mode, -com-
>                pat=4).  The other accepts constructs according to
>                the ANSI/ISO standard (standards mode, -compat=5).
>                These two modes are incompatible with each other
>                because the ANSI/ISO standard forces significant,
>                incompatible changes in name mangling, vtable lay-
>                out, and other ABI details. These two modes are
>                differentiated by the -compat option as shown in
>                the following values.

You are misreading it. All this means is that they changed their ABI to be
able to support the ISO standard, not that they are using a standard ABI.
They are most certainly not.  We have 0 support for their ABI, so you
won't be able to debug in any useful way.

 > >                Value
Meaning > 
>                -compat=4      Compile for compatibility with C++
>                               4.0.1, C++ 4.1, and C++ 4.2 (Sets
>                               __cplusplus macro to 1.)
> 
>                -compat=5      Compile with full C++ 5.0 features.
>                               (Sets __cplusplus macro to
>                               199711L.)
> 
>                Defaults:
> 
>                If the -compat option is not specified, -compat=5
>                is assumed.  If only -compat is specified, -com-
>                pat=4 is assumed.
> 
>                Interactions:
> 
>                The -xarch=v9 option and the -compat[=4] option
>                are not supported when used together.
> 
> -----Original Message-----
> From: Michael Elizabeth Chastain [ mailto:chastain@cygnus.com ]
> Sent: Friday, March 23, 2001 9:23 AM
> To: gdb@sourceware.cygnus.com; tanvir.hassan@tumisoftware.com
> Subject: Re: using GDB 5 on Solaris 7 with Sun WS5.0
> 
> 
> Hi Tanvir,
> 
> > I have heard that someone might have changed GDB to do "lazy" loading
> > of symbols by reading them from the *.o instead of the exe and thus
> > obviating the need for "-xs", but I don't see any mention of this in
> > any of the source.
> 
> That is the "partial symtab" (psymtab) code.
> 
> > 2) the name mangling/vtable scheme of Sun WS5.0 is apparently using the
> > ISO/ANSI ABI standard and GDB cannot deal with it (it needs an new BFD
to
> > handle this?  or is there a generic name de-mangling place in the code?)
> 
> Recent snapshots of gdb, and the current CVS version of gdb, operate with
> the new multi-vendor C++ ABI:
> 
>   http://reality.sgi.com/dehnert_engr/cxx/cxx-summary.html
> 
> If you could provide a URL or an ISO reference number for that "ISO/ANSI
> ABI standard", I could check if it's the same as the "new ABI" standard
> that we're working on supporting.
> 
> Michael Elizabeth Chastain
> <chastain@redhat.com>
> "love without fear"
> 
From ac131313@cygnus.com Fri Mar 23 18:23:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Announce <gdb-announce@sources.redhat.com>, GDB Discussion <gdb@sources.redhat.com>
Subject: [gdb] OBSOLETE m88k platform
Date: Fri, 23 Mar 2001 18:23:00 -0000
Message-id: <3ABC0525.CADF7070@cygnus.com>
X-SW-Source: 2001-03/msg00262.html
Content-length: 641

[Reply-to: GDB Discussion < gdb AT sources DOT redhat DOT com > ]

Hello,

As part of GDB 5.1, the m88k platform has been identified as a candidate
for obsolescence.  This platform:

        o       definitly no longer builds

        o       has no active maintainer

``Configurations that have been declared obsolete in this release have
been commented out.  Unless there is activity to revive these
configurations, the next release of GDB will have their sources
permanently REMOVED.''

If you have any comments or questions on this, please send them to the
GDB Discussion group.

        Andrew

Andrew Cagney
Acting Head GDB Maintainer
From ac131313@cygnus.com Fri Mar 23 18:28:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Announce <gdb-announce@sources.redhat.com>, GDB Discussion <gdb@sources.redhat.com>
Subject: [gdb] OBSOLETE Macintosh(tm) MPW(tm) platform
Date: Fri, 23 Mar 2001 18:28:00 -0000
Message-id: <3ABC062A.AE99D47@cygnus.com>
X-SW-Source: 2001-03/msg00263.html
Content-length: 729

[Reply-to: GDB Discussion < gdb AT sources DOT redhat DOT com > ]

Hello,

	Please note: This is not MacOS X

As part of GDB 5.1, the Macintosh(tm) MPW(tm) platform has been
identified as a candidate for obsolescence.  This platform:

        o       probably no longer builds

        o       still uses *-xdep.c

        o       has no active maintainer

``Configurations that have been declared obsolete in this release have
been commented out.  Unless there is activity to revive these
configurations, the next release of GDB will have their sources
permanently REMOVED.''

If you have any comments or questions on this, please send them to the
GDB Discussion group.

        Andrew

Andrew Cagney
Acting Head GDB Maintainer
From eliz@delorie.com Sat Mar 24 00:44:00 2001
From: Eli Zaretskii <eliz@delorie.com>
To: bronson@trestle.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: Trapping system calls
Date: Sat, 24 Mar 2001 00:44:00 -0000
Message-id: <200103240844.DAA06451@indy.delorie.com>
References: <20010322105918.H16210@trestle.com>
X-SW-Source: 2001-03/msg00264.html
Content-length: 435

> Date: Thu, 22 Mar 2001 10:59:18 -0800
> From: bronson@trestle.com (Scott Bronson)
> 
> Is there any way to break into GDB when a particular system call
> is made?  I want to trap every ioctl of a certain type.  Short
> of scattering thousands of breakpoints throughout the code, I could
> find no way of doing this.

Is there any reason why you couldn't put a breakpoint inside ioctl and
filter the calls with breakpoint conditions?
From eliz@delorie.com Sat Mar 24 00:49:00 2001
From: Eli Zaretskii <eliz@delorie.com>
To: ac131313@cygnus.com
Cc: gdb@sources.redhat.com
Subject: Re: TODO vs bug data base
Date: Sat, 24 Mar 2001 00:49:00 -0000
Message-id: <200103240849.DAA06565@indy.delorie.com>
References: <3ABA1637.18A2EE1C@cygnus.com>
X-SW-Source: 2001-03/msg00265.html
Content-length: 905

> Date: Thu, 22 Mar 2001 10:11:51 -0500
> From: Andrew Cagney <ac131313@cygnus.com>
> 
> Does the bug tracking database superseed the bulk of the TODO file?
> 
> I don't think the bug system can completly replace the TODO file - I'll
> still expect to see it used to publically record GDB's release status
> and file more generic TODO items.

IMHO, TODO is not a repository for bugs, and neither should it be used
for tracking bugs.  Instead, it should include more general goals of
GDB development.  Bugs should only be included there if they require
thorough rewrites of large portions of code.  For example, the
problems with supporting the new C++ ABI is something worthy of a TODO
item, but only as a general issue, not a list of specific problems.

If we need some list of specific bugs that should be solved before the
next release is made, they should IMHO go into a separate file, not
into TODO.
From eliz@delorie.com Sat Mar 24 01:02:00 2001
From: Eli Zaretskii <eliz@delorie.com>
To: ac131313@cygnus.com
Cc: gdb@sources.redhat.com
Subject: Re: demangle.h and ucase enums?
Date: Sat, 24 Mar 2001 01:02:00 -0000
Message-id: <200103240902.EAA06844@indy.delorie.com>
References: <3ABA364A.BCB09EA4@cygnus.com>
X-SW-Source: 2001-03/msg00266.html
Content-length: 1427

> Date: Thu, 22 Mar 2001 12:28:42 -0500
> From: Andrew Cagney <ac131313@cygnus.com>
> 
> http://gcc.gnu.org/codingconventions.html
> http://www.gnu.org/prep/standards_25.html#SEC25
> 
> ``Please use underscores to separate words in a name, so that the Emacs
> word commands can be useful within them. Stick to lower case; reserve
> upper case for macros and enum constants, and for name-prefixes that
> follow a uniform convention.''
> 
> Does anyone know how this should be interpreted?

I think you need to take a good look at Emacs sources to understand
what is meant by ``name-prefixes that follow a uniform convention'' ;-).

Emacs sources use the_lower_case_with_underscores for naming functions
and variables.  They use upper-case letters in functions and variables
which have special meaning.  For example, each primitive whose name in
Lisp is primitive-function is defined in C as Fprimitive_function, and
each variale known in Lisp as built-in-variable is defined in C as
Vbuilt_in_variable.

These F and V prefixes are certainly following a uniform convention.

> I've been working on the simplistic interpretation of ``enums are in
> upper case'' but, looking at demangle.h other interpretations are
> possible.

Err... what do you see in demangle.h that is pertinent to the above
issue?  I don't see anything except that they use lower case for
enums, which AFAIK is quite a wide-spread habit, including in Emacs.
From mcmahill@mtl.mit.edu Sat Mar 24 05:24:00 2001
From: mcmahill@mtl.mit.edu
To: gdb@sources.redhat.com
Subject: m88k
Date: Sat, 24 Mar 2001 05:24:00 -0000
Message-id: <Pine.SOL.3.96.1010324082045.13425B-100000@bitter.mit.edu>
X-SW-Source: 2001-03/msg00267.html
Content-length: 478

Hi,

I've heard m88k is scheduled for being removed.  There are a small handful
of people who i think are planning a m88k port of netbsd and I think that
there was some work in the openbsd camp too.

it will be several more months until i have any time to put in to it, but
i'd hoped to hack some on an m88k box myself.  it currently runs mach, but
i'd like to 'fix' that.

so i guess the only point of my email is to note that there are at least a
few potential users.

-Dan

Re: gdb/remote - I/O

[Mark Salter]

>>>>> Andrew Cagney writes:

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


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.

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.

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.

--Mark

Re: gdb/remote - I/O

[Fernando Nasser]

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

Re: gdb/remote - I/O

[Andrew Cagney]

> 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

Re: gdb/remote - I/O

[Todd Whitesel]

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

I prefer the implementation where target I/O is treated like a general
syscall request, which always blocks on the host. After all, it's really
for debugging and bootstrapping, not production -- and you gain a lot of
flexibility by doing it this way.

On the target, a syscall acts just like a breakpoint except that some
extra "I'm a syscall!" information is sent up too. For example, the
syscall number and the first three argument registers, which covers
all of your basic syscalls.

The target then just sits and waits to be manipulated with register/memory
commands, and eventually gets a command sequence telling it to write the
return register and 'errno flag' register and to continue.

On the host, a target that stops on a syscall gets processed through logic
which feels somewhat like the "should we continue stepping or not?" paths
in The Code Formerly Known As WaitForInferior. The host translates the
syscall to native bit-flags and such and attempts to execute it, including
simulated I/O (you need some minimal buffering here, nothing complicated).

If the requested syscall completes immediately, great. Diddle the target
and resume it. But if it doesn't, then you put the inferior into a state
which says "blocked on I/O" that is generally equivalent to "running" but
tells the event loop to keep checking to see if the target I/O can be
completed. Presumably this involves some combination of select/poll,
non-blocking read's, interaction with GUI's, etc.

The main things to keep straight are that the target PC has to remain at
the syscall instruction itself UNTIL the syscall is completed. This allows
you to process a user-level stop request by simply dropping the syscall and
declaring the target stopped. If the target is then continued at the same
PC, the syscall is simply re-executed.

Todd Whitesel
toddpw @ best.com

Re: gdb/remote - I/O

[Andrew Cagney]

Todd Whitesel wrote:

> I prefer the implementation where target I/O is treated like a general
> syscall request, which always blocks on the host. After all, it's really
> for debugging and bootstrapping, not production -- and you gain a lot of
> flexibility by doing it this way.

syscall?  Ah, you're thinking of UNIX :-)

> On the target, a syscall acts just like a breakpoint except that some
> extra "I'm a syscall!" information is sent up too. For example, the
> syscall number and the first three argument registers, which covers
> all of your basic syscalls.

> The target then just sits and waits to be manipulated with register/memory
> commands, and eventually gets a command sequence telling it to write the
> return register and 'errno flag' register and to continue.
> 
> On the host, a target that stops on a syscall gets processed through logic
> which feels somewhat like the "should we continue stepping or not?" paths
> in The Code Formerly Known As WaitForInferior. The host translates the
> syscall to native bit-flags and such and attempts to execute it, including
> simulated I/O (you need some minimal buffering here, nothing complicated).

I was waiting for someone to head down that path :-)

While a ``really cool feature'' I think, like the other proposal to make
things truely bi-directional it is getting away from the current
protocol's principal objective - to be as simple as possible.

I don't think a ``syscall'' mechanism would need any protocol changes
(just a minor reimplementation of GDB's target stack ;-)  I'd expect
something like a new target layer that would set a breakpoint on
syscall() and then intercept any thread-stopped event for that
breakpoint.  The layer would then manipulate the target and resume it.

I think the emphasis here should be on identifying just sufficient
functionality to provide the primative console.  Mark's point about the
target not having a break mechanism is the key - my original proposal
was flawed since it assume that GDB could directly interrupt the target.

	Andrew

Re: gdb/remote - I/O

[Andrew Cagney]

"J.T. Conklin" wrote:
> 
> >>>>> "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.

As Frank noted, the testsuite exploits it.

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

I suspect we're stuck with the situtation that a ``stop'' or ``break''
should be out-of-band.  I'm actually suprised that no one has suggested
sending a real BREAK instead of that cntrl-c.

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

It is part of their custom stop packet (N).
It turns out that some of the more exotic PDA OS's could also benefit
from a section offsets packet.

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

That is the thing.  While it would be nice if the remote target didn't
stop, in reality, it does.  For any of these events to be passed back to
GDB, the target has to stop for at least a short period of time.

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

These are both good ideas:

	o	separate the GDB remote protocol
		from its transport layer

	o	implement a new transport
		that supports multiple channels

however that is separate to changing the way the current remote protocol
works.

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

At some level or another, these events need to be synchronized.  For the
target to send console output back through to GDB it will need to
synchronize its self with with the debug server.

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

See Mark and Frank's comments about debugging and testing.
(I actually suspect it would never be used in a toy/trade-show demo - a
demo printing ``hello world'' would just be laughed at by marketing :-)

> Andrew> Input:

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

Actually, I underestimated!  See Mark's comment about no interrupt and
no timer.  On some targets it just ain't possible.

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

Yes, this was wrong.  Marks's pointed out that the target should poll.

	Andrew

Re: gdb/remote - I/O

[Andrew Cagney]

Just an additional datapoint on this.

The qRcmd packet (my fault) and the tracepoint packets (I've been
reading C code) both use the existing ``O'' packet to send additional
output back from the target during a query.

The obvious question is where exactly that ``O'' packet is ment to be
going - gdb_stdtarg, gdb_stdlog or gdb_stdout.  If it is gdb_stdout and
there is a pager things can get really complicated.

	Andrew

Re: gdb/remote - I/O

[Fernando Nasser]

Andrew Cagney wrote:
> 
> Just an additional datapoint on this.
> 
> The qRcmd packet (my fault) and the tracepoint packets (I've been
> reading C code) both use the existing ``O'' packet to send additional
> output back from the target during a query.
> 
> The obvious question is where exactly that ``O'' packet is ment to be
> going - gdb_stdtarg, gdb_stdlog or gdb_stdout.  If it is gdb_stdout and
> there is a pager things can get really complicated.
> 

We do have two different kinds of output coming from the target: output
produced by the os/monitor/stub or whatever we are talking to and the
output from the application (little bit of semi-hosting).

Fortunately for us, they happen at different times.  When the program is
running (after run or step) the output can be assumed to be from the
program and should go to gdb_stdtarg.  When the program is not running
the output can only be from the controlling software, and we can send it
to gdb_stdout.


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: gdb/remote - I/O

[J.T. Conklin]

>>>>> "Fernando" == Fernando Nasser <fnasser@redhat.com> writes:
Fernando> We do have two different kinds of output coming from the
Fernando> target: output produced by the os/monitor/stub or whatever
Fernando> we are talking to and the output from the application
Fernando> (little bit of semi-hosting).
Fernando>
Fernando> Fortunately for us, they happen at different times.  When
Fernando> the program is running (after run or step) the output can be
Fernando> assumed to be from the program and should go to gdb_stdtarg.
Fernando> When the program is not running the output can only be from
Fernando> the controlling software, and we can send it to gdb_stdout.

I've been thinking about the proposed changes to the remote protocol
since they were first brought up.  I've been trying to come to terms
with an issue myself before I put it up for discussion in a coherent
manner, but since I'm not making much progress on my own I thought I'd
better better share what I've got.

Question: Does the remote protocol support systems where other threads
continue to execute when one being debugged is halted.  This is a hard
question to answer, since the existing implementation of both GDB and
the debug agents (stubs, gdbserver, and I suppose libremote (although
I've never seen it)) assume the target completely stops.  But does the
protocol itself allow this?  From what I can tell, it can.  If it does
not, it almost does --- especially when you consider how loosely some 
of the commands are defined.

The proposals wrt. I/O seem to require the target to halt for I/O,
which precludes enhancing GDB and the debug agents to take full
advantage of the remote protocol.  I ask whether or not this is 
desirable?

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: gdb/remote - I/O

[Frank Ch. Eigler]

jtc wrote:

: [...]
: Question: Does the remote protocol support systems where other threads
: continue to execute when one being debugged is halted.  [...] But does 
: the protocol itself allow this?  From what I can tell, it can.  If it does
: not, it almost does --- especially when you consider how loosely some 
: of the commands are defined.

While the wire protocol is indeed rather loose, the process model
assumed by the dominant party (gdb) should be respected.  I would
ascribe looseness not to encouraging creative implementations, but to
systemic lack of formality.

If your target requires some mixed halted/running thread states, and
you run into problems with gdb's model, you could consider switching
to a multi-process rather than multi-thread debugging model.


: The proposals wrt. I/O seem to require the target to halt for I/O,
: which precludes enhancing GDB and the debug agents to take full
: advantage of the remote protocol.  I ask whether or not this is 
: desirable?

Is there anything special about I/O in this way?  If your unusual
target, when responding to a ^C/break from gdb, decides to stop just
one thread, it could do the same thing for I/O.  It could suspend the
output-causing thread; it could suspend any old thread for enqueueing
input.


- FChE

Re: gdb/remote - I/O

[J.T. Conklin]

>>>>> "Frank" == Frank Ch Eigler <fche@redhat.com> writes:

Frank> jtc wrote:
Frank> : Question: Does the remote protocol support systems where
Frank> : other threads continue to execute when one being debugged is
Frank> : halted.  [...] But does the protocol itself allow this?  From
Frank> : what I can tell, it can.  If it does not, it almost does ---
Frank> : especially when you consider how loosely some of the commands
Frank> : are defined.

Frank> While the wire protocol is indeed rather loose, the process
Frank> model assumed by the dominant party (gdb) should be respected.
Frank> I would ascribe looseness not to encouraging creative
Frank> implementations, but to systemic lack of formality.

Frank> If your target requires some mixed halted/running thread
Frank> states, and you run into problems with gdb's model, you could
Frank> consider switching to a multi-process rather than multi-thread
Frank> debugging model.

The reason I asked is that from time to time over the last few years,
there has been talk of enhancing GDB to use a more complicated model
where systems with multiple (possibly heterogenous) processors, each
with multiple processes, each with multiple threads could be debugged.
If this is still the goal, we need to consider whether each decision
we make takes us closer or precludes us from reaching the goal.

Frank> : The proposals wrt. I/O seem to require the target to halt for I/O,
Frank> : which precludes enhancing GDB and the debug agents to take full
Frank> : advantage of the remote protocol.  I ask whether or not this is 
Frank> : desirable?

Frank> Is there anything special about I/O in this way?  If your
Frank> unusual target, when responding to a ^C/break from gdb, decides
Frank> to stop just one thread, it could do the same thing for I/O.
Frank> It could suspend the output-causing thread; it could suspend
Frank> any old thread for enqueueing input.

With this model, you might be connected to the target (thus be able to
handle I/O) but not attached to any one thread.  I've debugged vxWorks
targets this way, where the system is free running and all I can do is
memory reads and writes.  This loses if I/O can only be handled while
waiting for an inferior thread/process.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: gdb/remote - I/O

[Andrew Cagney]

Hello,

Given the recent discussion on the qSymbol packet and a comment that the 
target should be able to initiate such an interaction, I'd like to 
propose the following as a possible interaction.


	<target running>

	<- T00;qSymbol;qIn;
.
		i.e. the target can stop and
		drop a big hint that it would
		like to be probed for the given
		packet - here qSymbol and qIn
		The target has also bundled up
		some output data.

	-> qIn;<bytes-of-input>

		Something goes in the .....
		it might be bytes of input
		it might be something else

	<- "" packet not recognized
	<- "OK" nothing at present


	-> qSymbol....
	<- ....
	-> qSumbol....
	<- ....

	-> C
		The exchange is finished continue
		the target.

	<target resumes execution>

The main point is that this allows the target to initiate an interaction 
by pigybacking what they want on a dummy ``T'' packet while at the same 
time leaving the host in control - all interactions still being host 
initiated.

	Andrew