gdb/remote - I/O

Andrew Cagney
2001-03-23T15:36:00Z

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 (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
<- OK
-> c (continue)
.....
<- T.... (stop)

A refinement might see:

-> c (continue)
<BREAK>
<- T<sigint> (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
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