Re: -Wmissing-prototypes ...

[Andreas Jaeger <aj@suse.de>]

>>>>> Eli Zaretskii writes:

>> My current list is:
>> 
>> --enable-build-warnings=-Werror\
>> ,-Wimplicit\
>> ,-Wreturn-type\
>> ,-Wcomment\
>> ,-Wtrigraphs\
>> ,-Wformat\
>> ,-Wparentheses\
>> ,-Wpointer-arith\
>> ,-Wmissing-prototypes\
>> ,-Woverloaded-virtual\
[...]
Eli> Here are the patches for go32-nat.c to allow it to compile with all
Eli> kinds of -Wfoo switches (I added switches beyond those mentioned above).

Eli> +static void print_387_status (unsigned, struct env387 *);
Shouldn't this be unsigned int?  AFAIK the new ISO C99 standard
mandates it - and it doesn't harm here.

Eli>  static void
Eli> -print_387_status (unsigned short status, struct env387 *ep)
Eli> +print_387_status (unsigned status, struct env387 *ep)
Again: unsigned int
Eli> +  print_387_control_word ((unsigned)ep->control & 0xffff);
unsigned int

I didn't look at the rest,
Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.rhein-neckar.de
From grante@visi.com Thu Dec 02 07:49:00 1999
From: Grant Edwards <grante@visi.com>
To: William Gatliff <gatliff@haulpak.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Standard GDB Remote Protocol
Date: Thu, 02 Dec 1999 07:49:00 -0000
Message-id: <19991202094847.A1826@visi.com>
References: <199911231303.IAA01523@mescaline.gnu.org> <npr9hg2a9t.fsf@zwingli.cygnus.com> <199911251715.MAA09225@mescaline.gnu.org> <npzovvc04o.fsf@zwingli.cygnus.com> <199912010821.DAA27130@mescaline.gnu.org> <npogca9tb8.fsf@zwingli.cygnus.com> <3845AB0E.3795D99E@ozemail.com.au> <5md7sql00o.fsf@jtc.redbacknetworks.com> <3845F45A.38EA29CF@ozemail.com.au> <384685A7.15184EB1@haulpak.com>
X-SW-Source: 1999-q4/msg00418.html
Content-length: 1858

On Thu, Dec 02, 1999 at 08:43:51AM -0600, William Gatliff wrote:

> > Packet Structure:
> >
> > Simple structure, obviously originally designed to be able to be driven
> > manually from a TTY. (Hence it's ASCII nature.) However, the protocol has
> > evolved quite significantly and I doubt it could still be used very
> > efficiently from a TTY.
> 
> True, but it can still be *monitored* quite effectively with a TTY,

And this is a Very Good Thing.  Debugging the RDI target stuff was a
pain because of the binary packet format.  Even after adding of
packet-logging routines, it still wasn't obvious what was wrong.
Fortunately, I do that sort of stuff for a living and have an HP
protocol analyzer sitting handy.  :)

Most of the features in the RDI packet protocol either don't work or
aren't used, so a simpler ASCII protocol would have served just as
well.

An ASCII protocol also allows you to whip together a quick simulator
for either end using something like expect (and netcat if you want to
do TCP/IP).  This can save your ass big time when trying to isolate
problems.

> and simple things like a ? query are still possible.  If I'm using a
> TTY then I'm desperate anyway, so I'm willing to put up with a
> little pain.  Go to a non-ASCII protocol, however, and the TTY
> option is right out altogether, no matter how desperate I am!
> 
> If efficiency/throughput is a problem, then go to ethernet.  At
> 10/100Mbps, even the overhead of ASCII isn't a problem for most
> targets I can think of.

Definitely.  The RDI packet stuff is binary, but it's still only
pleasant to use via Ethernet.  For example, a "next" involves
exchanging about a half-dozen packets, and even when they're in
binary, doing it via RS-232 involves an annoyinge delay when you're
used to seeing the green arrow in DDD move instantly..

-- 
Grant Edwards
grante@visi.com
From ezannoni@cygnus.com Thu Dec 02 08:31:00 1999
From: Elena Zannoni <ezannoni@cygnus.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: using '-x -' to read gdb script from stdin
Date: Thu, 02 Dec 1999 08:31:00 -0000
Message-id: <14406.40674.819682.91859@kwikemart.cygnus.com>
References: <5miu2hhgkx.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q4/msg00419.html
Content-length: 2091

J.T. Conklin writes:
 > I updated one of our year old GDB executables a week or so ago, and
 > was notified that one of the scripts used by SQA failed to work.  I
 > tracked it down to the following bit of code that was ifdef'd out 
 > earlier this year.
 > 
 > >From main.c:
 >               /* NOTE: I am commenting this out, because it is not clear 
 >                  where this feature is used. It is very old and
 >                  undocumented. ezannoni: 1999-05-04 */
 >     #if 0
 >               if (cmdarg[i][0] == '-' && cmdarg[i][1] == '\0') 
 >                 read_command_file (stdin);
 >               else
 >     #endif 
 > 
 > 
 > The script invoked gdb like this:
 >     echo list "*$addr" | $gdb -batch -x - $file | head -1 
 > 
 > [ I know, I should be using addr2line.  But this script was written 
 >   before addr2line existed. ]
 > 
 > Since all of our systems support /dev/stdin, I patched up our script
 > accordingly.  But I wonder whether support for - should be reenabled.
 > Is there any reason why not?
 > 
 >         --jtc
 > 

JT,

If I remember correctly, invoking gdb with '-x -'
would start the command_loop() via read_command_file(), instead of
via captured_command_loop(). In case of async (which is now the default), 
the traditional command_loop() is not called, because gdb_init() sets
command_loop_hook to cli_command_loop(). 

So we would have started the regular command loop, even though all the
necessary stuff for async was set up. Bad interactions would follow.

Since that option was not documented, it was decided to get rid of it
if nobody was going to be penalized.  It may be still possible to
clean things up but I just noticed that it is not just a matter of
eliminating the #if 0, unfortunatley, because more surrounding code
has also been deactivated.

Using the source command works because that is invoked after the main
command loop has already started.

I can put this on my to do list, but it will be a while before I can
get to it.  Feel free to give it a try if you want.

Elena

 > -- 
 > J.T. Conklin
 > RedBack Networks
From sasumner@juno.com Thu Dec 02 09:51:00 1999
From: Scott A Sumner <sasumner@juno.com>
To: gdb@sourceware.cygnus.com
Subject: gdb build troubles
Date: Thu, 02 Dec 1999 09:51:00 -0000
Message-id: <19991201.205719.-370075.0.sasumner@juno.com>
X-SW-Source: 1999-q4/msg00420.html
Content-length: 1748

Hi,

I'm trying to build gdb with the Cygwin 1.0 CD toolset for an m68k
target.

Here's what I do:

bash-2.03$ ../gdb-4.18/configure --target=m68k-coff

And here's what happens:

Configuring for a i586-pc-cygwin32 host.
# post-target:
 intl mmalloc libiberty opcodes bfd readline gash db tcl tk tcl8.1 tk8.1
tclX it
cl tix libgui byacc flex bison binutils ld gas gcc sim gdb make patch
prms send-
pr gprof gdbtest tgas etc expect dejagnu ash bash bzip2 m4 autoconf
automake lib
tool ispell grep diff rcs cvssrc fileutils shellutils time textutils
wdiff find
emacs emacs19 uudecode hello tar gzip indent recode release sed utils
guile perl
 apache inet gawk findutils snavigator libtool gettext zip libtermcap
dosrel
grep: (standard input): Permission denied (EACCES)
grep: (standard input): Permission denied (EACCES)
 intl mmalloc libiberty opcodes bfd readline gash db tcl tk tcl8.1 tk8.1
tclX it
cl tix libgui byacc flex bison binutils ld gas gcc sim gdb make patch
prms send-
pr gprof gdbtest tgas etc expect dejagnu ash bash bzip2 m4 autoconf
automake lib
tool ispell grep diff rcs cvssrc fileutils shellutils time textutils
wdiff find
emacs emacs19 uudecode hello tar gzip indent recode release sed utils
guile perl
 apache inet gawk findutils snavigator libtool gettext zip libtermcap
dosrel
grep: (standard input): Permission denied (EACCES)
grep: (standard input): Permission denied (EACCES)
<REPEATS FOREVER ANNOYINGLY SPINNING THE FLOPPY DRIVE>

Can anyone give me a hint as to my problem?

Scott A. Sumner

___________________________________________________________________
Get the Internet just the way you want it.
Free software, free e-mail, and free Internet access for a month!
Try Juno Web: http://dl.www.juno.com/dynoget/tagj .
From jtc@redback.com Thu Dec 02 10:36:00 1999
From: jtc@redback.com (J.T. Conklin)
To: Elena Zannoni <ezannoni@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: using '-x -' to read gdb script from stdin
Date: Thu, 02 Dec 1999 10:36:00 -0000
Message-id: <5m4se1mbq3.fsf@jtc.redbacknetworks.com>
References: <5miu2hhgkx.fsf@jtc.redbacknetworks.com> <14406.40674.819682.91859@kwikemart.cygnus.com>
X-SW-Source: 1999-q4/msg00421.html
Content-length: 1367

>>>>> "Elena" == Elena Zannoni <ezannoni@cygnus.com> writes:
Elena> Since that option was not documented, it was decided to get rid
Elena> of it if nobody was going to be penalized.  It may be still
Elena> possible to clean things up but I just noticed that it is not
Elena> just a matter of eliminating the #if 0, unfortunatley, because
Elena> more surrounding code has also been deactivated.

Elena> I can put this on my to do list, but it will be a while before
Elena> I can get to it.  Feel free to give it a try if you want.

There's no rush.  Using /dev/stdin works for now, and I hope to adapt
the script to use binutils' addr2line utility in the near future.

After thinking this over a bit, reading commands from stdin may not be
the best way to support 'command line' batch scripting.  Perhaps it
should be done with a command line option instead.  Maybe something
like this:

        gdb -batch --eval "list *$addr"

The current command interpreter doesn't have a statement separator so
that multiple commands can be put on one line, but it may be possible
to add one.  I tried appending a semicolon to a handful of commands
and they all bailed out with syntax errors of one sort or another.

Something to think about.  Since my immediate problem has been solved,
I'm going to put this on the back burner.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From davidwilliams@ozemail.com.au Thu Dec 02 10:49:00 1999
From: David Williams <davidwilliams@ozemail.com.au>
To: "'gdb mail list'" <gdb@sourceware.cygnus.com>
Subject: exceptionHandler for 68K
Date: Thu, 02 Dec 1999 10:49:00 -0000
Message-id: <01BF3D51.ED385300.davidwilliams@ozemail.com.au>
X-SW-Source: 1999-q4/msg00422.html
Content-length: 418

Hi all,

Has anyone got an example of the exceptionHandler() function for the 68K 
(plain old 68000 core). The m68k-stub.c module  requires one (as explained 
in GDB manual). However it appears that this function must use its own 
special vector table to help identify the vector number (using return 
address magic!). It would just be nice to see some source code to clarify 
some issues for me.

TIA
David Williams.
From davidwilliams@ozemail.com.au Thu Dec 02 10:55:00 1999
From: David Williams <davidwilliams@ozemail.com.au>
To: "'gdb mail list'" <gdb@sourceware.cygnus.com>
Subject: gdb stack in stub
Date: Thu, 02 Dec 1999 10:55:00 -0000
Message-id: <01BF3D52.CD93EEA0.davidwilliams@ozemail.com.au>
X-SW-Source: 1999-q4/msg00423.html
Content-length: 596

Hi all,

I noticed that a 10K local stack is allocated in the m68k-stub.c for it own 
use when communcating with gdb. This seems excessive. I would like to leave 
the stub code in my final application so that I can debug in the field (via 
a special option). However it would be better if the stub consumed the 
least amount of system resources as possible.

Is there any problem with using my applications stack (if enough room is 
allocated for GDB usage in addition to normal usage)? My application always 
runs in supervisor mode.

What is likely max stack usage of GDB?

TIA
David Williams.
From jtc@redback.com Thu Dec 02 11:12:00 1999
From: jtc@redback.com (J.T. Conklin)
To: "davidwilliams@ozemail.com.au" <davidwilliams@ozemail.com.au>
Cc: "'gdb mail list'" <gdb@sourceware.cygnus.com>
Subject: Re: gdb stack in stub
Date: Thu, 02 Dec 1999 11:12:00 -0000
Message-id: <5mvh6hkvi6.fsf@jtc.redbacknetworks.com>
References: <01BF3D52.CD93EEA0.davidwilliams@ozemail.com.au>
X-SW-Source: 1999-q4/msg00424.html
Content-length: 1636

>>>>> "David" == David Williams <davidwilliams@ozemail.com.au> writes:
David> Hi all, I noticed that a 10K local stack is allocated in the
David> m68k-stub.c for it own use when communcating with gdb. This
David> seems excessive. I would like to leave the stub code in my
David> final application so that I can debug in the field (via a
David> special option). However it would be better if the stub
David> consumed the least amount of system resources as possible.
David>
David> Is there any problem with using my applications stack (if
David> enough room is allocated for GDB usage in addition to normal
David> usage)? My application always runs in supervisor mode.

Yes.  The problem occurs when you attempt an inferior function call.
GDB starts constructing a dummy stack frame at the saved stack ptr,
which overwrites the stack memory being used by the stub itself.

David> What is likely max stack usage of GDB?

The stub code itself doesn't use much stack, but the user-supplied
putDebugChar() and getDebugChar() functions might.  I typically do
i/o with loops polling UART registers, which isn't stack intensive.

I've measured stack use of our PowerPC based stub at less than 100
bytes.  A CPU like the m68k where function arguments and return
addresses are passed on the stack may take a bit more.

You might want to allocate a stack you know will be big enough,
initialize it with a given pattern, use the stub for a while and then,
examine the stack to determine where the pattern has been overwritten.
That should give you a good idea how to size the stack in your system.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From jtc@redback.com Thu Dec 02 15:04:00 1999
From: jtc@redback.com (J.T. Conklin)
To: "davidwilliams@ozemail.com.au" <davidwilliams@ozemail.com.au>
Cc: "'gdb mail list'" <gdb@sourceware.cygnus.com>
Subject: Re: exceptionHandler for 68K
Date: Thu, 02 Dec 1999 15:04:00 -0000
Message-id: <5mr9h5kkt7.fsf@jtc.redbacknetworks.com>
References: <01BF3D51.ED385300.davidwilliams@ozemail.com.au>
X-SW-Source: 1999-q4/msg00425.html
Content-length: 1692

>>>>> "David" == David Williams <davidwilliams@ozemail.com.au> writes:
David> Has anyone got an example of the exceptionHandler() function
David> for the 68K (plain old 68000 core). The m68k-stub.c module
David> requires one (as explained in GDB manual). However it appears
David> that this function must use its own special vector table to
David> help identify the vector number (using return address
David> magic!). It would just be nice to see some source code to
David> clarify some issues for me.

Although the debug stubs distributed with GDB can be used without
modification, there is no reason why you must do so.  

Exception handling mechanisms are target dependent.  If you're happy
with the exception mechanism you are currently using (or the one you
have designed, if you're not that far), In my opinion it is better to
adapt the debug stubs exception handler installation code rather than
to force your system to match.

All that being said...  

It's been a long time since I've used the m68k, but if I remember
correctly the addresses of exception handlers are stored in a 256
entry table, the address of which is stored in a exception vector
table base register.  

In C, you might do something like this to install an address:

        void *exc_tbl[256];

        void
        exceptionHandler(int vec, void *addr)
        {
                exc_tbl[vec] = addr;
        }

In assembly, the code might be something like this:

        # 
        # Inputs:
        #   d0 - vector
        #   d1 - address of exception handler
        #   a0 - address of exc_tbl
        #
        move.l  %d1,(%a0,%d0.l*4)

Hope this helps,

        --jtc

-- 
J.T. Conklin
RedBack Networks
From davidwilliams@ozemail.com.au Thu Dec 02 15:15:00 1999
From: David Williams <davidwilliams@ozemail.com.au>
To: "'gdb mail list'" <gdb@sourceware.cygnus.com>
Subject: RE: exceptionHandler for 68K
Date: Thu, 02 Dec 1999 15:15:00 -0000
Message-id: <01BF3D76.F8F982C0.davidwilliams@ozemail.com.au>
X-SW-Source: 1999-q4/msg00426.html
Content-length: 3671

Hi,
Although the debug stubs distributed with GDB can be used without
modification, there is no reason why you must do so.

Exception handling mechanisms are target dependent.  If you're happy
with the exception mechanism you are currently using (or the one you
have designed, if you're not that far), In my opinion it is better to
adapt the debug stubs exception handler installation code rather than
to force your system to match.

Good Advice, and in fact what I was already considering. However I wish to 
understand the exisiting m68k-stub.c better to decide if what is being done 
is useful and worth adapting. Please note my target (68EZ328) has a 68000 
core, not CPU32, so when exceptions occur there is no vector number stored 
on the stack.

I get the idea of what the m68k-stub.c (supplied with gdb4.18) is trying to 
do without understanding the full detail. The 68000 does not provide the 
vector number when an exception occurs. To get arround this the stub 
assumes that you orgainise the real 68K vectors to point to a table of 'jsr 
handler' op-codes. Then when the exception occurs the CPU stacks the 
current PC(program counter) and SR(status register) looks up the vector and 
loads the PC with the value in the vector. The new PC will be somewhere in 
the jsr table. The CPU then executes the jsr in the table which causes the 
CPU to stack the return address (location in the jsr table) and then jump 
to the exception handler. My problem is that I dont understand where this 
table of jsr's is located...

The m68k-stub has code to determine the exception number by taking the 
return address on the stack (the return address is the location in the jsr 
table) and adding 1530 and then dividing by 6.

The relevent comments in the source are

"Some explanation is probably necessary to explain how exceptions are 
handled.  When an exception is encountered the 68000 pushes the current 
program counter and status register onto the supervisor stack and then 
transfers execution to a location specified in it's vector table. The 
handlers for the exception vectors are hardwired to jmp to an address given 
by the relation:  (exception - 256) * 6.  These are decending  addresses 
starting from -6, -12, -18, ...  By allowing 6 bytes for
each entry, a jsr, jmp, bsr, ... can be used to enter the exception 
handler.  Using a jsr to handle an exception has an added benefit of 
allowing a single handler to service several exceptions and use the return 
address as the key differentiation.  The vector number can be computed from 
the return address by [ exception = (addr + 1530) / 6 ].
The sole purpose of the routine _catchException is to compute the exception 
number and push it on the stack in place of the return address. The 
external function exceptionHandler() is used to attach a specific handler 
to a specific m68k exception."

Any help would be appreciated.


All that being said...

It's been a long time since I've used the m68k, but if I remember
correctly the addresses of exception handlers are stored in a 256
entry table, the address of which is stored in a exception vector
table base register.

In C, you might do something like this to install an address:

        void *exc_tbl[256];

        void
        exceptionHandler(int vec, void *addr)
        {
                exc_tbl[vec] = addr;
        }

In assembly, the code might be something like this:

        #
        # Inputs:
        #   d0 - vector
        #   d1 - address of exception handler
        #   a0 - address of exc_tbl
        #
        move.l  %d1,(%a0,%d0.l*4)


Thanks for the code, unfortunately this does not address my problem - see 
notes above.
From sbjohnson@ozemail.com.au Thu Dec 02 16:19:00 1999
From: Steven Johnson <sbjohnson@ozemail.com.au>
To: gdb@sourceware.cygnus.com
Subject: Re: Standard GDB Remote Protocol
Date: Thu, 02 Dec 1999 16:19:00 -0000
Message-id: <38470CC1.1B0E5C27@ozemail.com.au>
References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <npr9hi321d.fsf@zwingli.cygnus.com> <199911231303.IAA01523@mescaline.gnu.org> <npr9hg2a9t.fsf@zwingli.cygnus.com> <199911251715.MAA09225@mescaline.gnu.org> <npzovvc04o.fsf@zwingli.cygnus.com> <199912010821.DAA27130@mescaline.gnu.org> <npogca9tb8.fsf@zwingli.cygnus.com> <3845AB0E.3795D99E@ozemail.com.au> <5md7sql00o.fsf@jtc.redbacknetworks.com> <3845F45A.38EA29CF@ozemail.com.au> <384685A7.15184EB1@haulpak.com>
X-SW-Source: 1999-q4/msg00427.html
Content-length: 5990

William Gatliff wrote:
> 
> Steven Johnson wrote:
> 
> > Packet Structure:
> >
> > Simple structure, obviously originally designed to be able to be driven
> > manually from a TTY. 
> 
> True, but it can still be *monitored* quite effectively with a TTY, and
> simple things like a ? query are still possible.  

Im not criticizing or suggesting a change, im making an observation.
Whether $ or STX or some other packet structure is used is of little
import. Advantageously, the GDB packet structure is complete and
independent from the message it contains. Which is a good thing. This is
very different from many "proprietary" binary protocols i've used where
the packet and message are confused and mingled, so that there is no
good separation of packet handling and messaging. I actually found this
a nice surprise, from all of the protocols i've dealt with few people
seem to realize the importance of this in good comms design.

> 
> If efficiency/throughput is a problem, then go to ethernet.
> 

I wasn't suggesting it was in-efficient to use from a program. I was
making the general statement that it would be difficult to debug a
target just using a TTY and a target with the stub. Efficiency meant,
time in working out the message to key in and deciphering the response.
You have no arguments from me that being able to easily observe the
message stream for the purposes of debugging an implementation is a good
thing.

> 
> Good suggestions, but I would prefer that these be general stub design
> guidelines that aren't enforced by gdb.  Let gdb be as flexible as
> possible, so that it will work with super-smart stubs that do all the
> timing stuff properly, as well as stubs that are minimally written.
>

Yes, here's the issue. The document is completely lacking in stub
implementation guidelines. IMHO, there needs to be a section of the
protocol (or comments throughout it) that give this sort of information
and advice to implementers of stubs. An implementer can then take it or
leave it, but at least the document needs to advise how a well behaved
stub could/should operate. There needs to be more than just "Here is a
Packet", there also needs to be documentation along the lines of "Here
is a Packet, a receiver should do this when it gets it. Possible
problems in reception are, some solutions to these problems are." It
would add meat to the bones that are currently described and aid in the
implementation/debugging of a stub. 
 
>
> Gdb is supposed to be a debugging aid; I would prefer that all the protocol
> stuff not get in the way of its fundamental mission.
> 

I'm not suggesting it does.

> Also, how do you measure byte times on most debugging hosts, particularly
> at 115K (my bit rate of choice) and higher? 
>....<snip>
> 

No arguments here either, I was speculating about possible solutions. I
wasn't saying this must be done. I would agree there are many ways to
skin that cat, and some are easier than others, depending on your host.
I also recognize that stubs probably don't do this now and the world
hasn't come to an end. 

> > There is no documentation of the recovery procedure, Does GDB retransmit
> > if its message is responded to with a NAK? If not, what does it do? How
> > is the target supposed to identify and handle retransmits from GDB.
> 
> > What happens if something other than + or - is received when ACK/NAK is
> > expected. (For example $).
> 
> >From my own experience, remote.c is kinda fragile where stuff like this is
> concerned.  I had been intending to look into this myself next year, but by
> then someone else will have certainly beaten me to it.  I think some
> improvements have already been made.
> 

I see this as a far more important issue than the timeout stuff,
although they are related. Remote.c is probably fragile, because there
is no documentation on how it should work. It wouldn't surprise me if
there was inconsistency of the implementation in GDB because of this.

> > Character Escaping: The mechanism of Escaping the characters is not
> > defined. Further it is only defined as used by write mem binary.
> 
> That's because this is the only place where it is needed, AFAIK.  And,
> since X is optional (and support for it is detected automatically by gdb),
> that means that I don't have to implement it if I don't want to.  Bonus for
> super-minimal stubs.
> 

Again I agree with this. I was making the observation that Character
Escaping is likely to become more prevalent as the protocol evolves. To
define character escaping around one message could create a situation
where different messages that require it implement different mechanisms.
There is evidence of that occurring in other messages, like the ':'
shouldn't be used, but some messages do statement. 

What would probably be more appropriate is to state how escaping is
performed where required as part of the base level protocol. Then in the
message put a statement like, "This message contains binary data and
must be Escaped using the standard escaping mechanism defined above".

This way if you don't implement any of those messages, you don't need to
implement Escaping. But it advantageous in that it defines how escaping
will be used in any/all messages that require it. I think the same
should be said for RLE. Maybe each message needs a check list that
states what features it may use like this:

My new Message          U                    My comments on this message
                                             Uses RLE: NO
                                             Uses ESC: YES

At least this would clearly state where both of these mechanisms can be
used, and where they can't.


Further, Im not stating any implementation should change. What Im trying
to do is come to terms with the documented protocol. Identify weaknesses
in that documentation and propose ways the document can be strengthened
to more accurately reflect what is desired of an implementation.

Steven Johnson
Managing Director
Neurizon Pty Ltd
From shebs@cygnus.com Thu Dec 02 19:05:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: alexs@cygnus.co.uk
Cc: gdb@sourceware.cygnus.com
Subject: Re: Multi-threaded debugging within GDB & eCOS
Date: Thu, 02 Dec 1999 19:05:00 -0000
Message-id: <199912030305.TAA24626@andros.cygnus.com>
References: <77kid9$pqp$1@korai.cygnus.co.uk>
X-SW-Source: 1999-q4/msg00428.html
Content-length: 1641

   From: "Alex Schuilenburg" <alexs@cygnus.co.uk>
   Date: Thu, 14 Jan 1999 11:04:23 -0000

   Could someone describe how gdb would handle the following situation in
   debugging multiple threads using gdb (particularly on eCOS)? Has anyone
   thought of this scenario before?

   1) gdb is tracking thread A, which claims a system mutex.
   2) Either a context switch occurs or the user suspends thread A and
      switches to debugging thread B (which itself is suspended).
   3) While stepping over fn calls within B, the code attempts to claim
      the mutex already owned by A. Hence B will never return from the call
      to the next temporary breakpoint until A is resumed and releases the
      mutex.

   Will gdb lock up? Is there any mechanisim to allow gdb to detect/catch this
   scenario and report back to the user what has happened?

GDB will "lock up".  More precisely, GDB will sit quietly waiting for
the target to do something, not realizing that the user has caused a
deadlock by manually suspending thread A.  This is as expected, since
GDB has no way to know that the program is in this state.  In
practice, the user gets impatient, hits ^C, sees the current state,
and goes "oh yeah, my fault" and fixes.

GDB's default behavior is to give all threads a chance to run when
resuming, which generally prevents this kind of situation.  We
introduced the scheduler-locking flag for those cases where the user
really really needs to lock out other threads, even if it might mean
the thread being stepped will block.

(I'd be interested to know if you have workarounds for this
fundamental problem though.)

								Stan
From qqi@world.std.com Thu Dec 02 19:14:00 1999
From: Quality Quorum <qqi@world.std.com>
To: gdb@sourceware.cygnus.com
Subject: gdb & wiggler
Date: Thu, 02 Dec 1999 19:14:00 -0000
Message-id: <Pine.SGI.3.95.991202221018.1589A-100000@world.std.com>
X-SW-Source: 1999-q4/msg00429.html
Content-length: 383

Hi, 

I am working on the piece of code which will proived gdb-server like
servies for embedded systems. I would like to allow people 
to use for interfacing with proprietary software (similar to 
gdb <->wiggler.dll interface). I would prefer to publish it under 
GPL, however, I have doubts whether or not interface like 
gdb <-> wiggler is compliant with GPL ?

Thanks,

Aleksey