Re: dcache

[Andrew Cagney <ac131313@cygnus.com>]

"J.T. Conklin" wrote:
> 
> The dcache_flush() routine throws away its contents.  I don't know
> about you guys, but to me flushing a cache implies writing out the
> contents, is there any objection to renaming this function to some-
> thing like dcache_invalidate()?  The dcache_writeback() function is
> a real cache flush, but writeback is just as descriptive.  I see no
> reason to rename it to dcache_flush().

Yes, long ago I thought I knew what a flush function did.  Since reading
GDB's code I've become very confused :-)
serial.c has exactly the same problem.  It's ``drain()'' function
implements flush().  Dig dig, hmm, serial's flush dates back to
1993/06/30 while dcache is around that same period (different authors
though :-).

> Implies that GDB writes reads and memory in small chunks instead of
> larger chunks, and the dcache speeds this up by coalescing multiple
> small transactions into larger ones.  Does anyone know the truth of
> this implication, especially for writes?

Ignoring the dcache() gdb definitly likes to perform small writes (1-4
bytes).  The easiest case to monitor would be an inferior function call.

> I ask because the current implementation is a writethrough cache ---
> small writes aren't going to be combined.  I suspect in most cases, if
> target memory is cached at all, this is the desired behavior.  (e.g. A
> user setting a global flag probably wants that change to be reflected
> immediately, so that another thread of execution can act upon it).

The behavour should be the same as with registers.  As far as the user
can see, operations are write through.
However, internally, gdb would benefit from a write back mechanism when
implementing inferior function calls.

> Are there any circumstances where a writeback cache would be useful?
> While I'm fiddling around with dcache, it would not be difficult to
> add.  Every place there's a dcache_flush() in target code would be
> replaced with something like dcache_writebackinvalidate(), and the
> dcache_xfer_memory could avoid writing the data if the memory region
> was configured for a writeback behavior.

The test call-ar-st.exp would benefit significantly!

	Andrew
From eliz@delorie.com Fri Jun 16 09:58:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: kwho@visto.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: Ver 5.0 Configuration Problem with DJGPP
Date: Fri, 16 Jun 2000 09:58:00 -0000
Message-id: <200006161658.MAA29731@indy.delorie.com>
References: <200006160212.FAA21931@is.elta.co.il>
X-SW-Source: 2000-06/msg00137.html
Content-length: 1168

> From: "Ka Wai Ho" <kwho@visto.com>
> Date: Thu, 15 Jun 2000 19:13:33 -0700
> 
> I get the follow message when configure GDB 5.0 

Thank you for your report.

> D:\DJGPP\gdb-5.0>sh ./gdb/config/djgpp/djconfig.sh 
> Checking the unpacked distribution... ok. 
> Editing configure scripts for DJGPP... 
> Running the configure script... 

This is already a sign of trouble: there should have been several
lines between the last line above and the line before that saying
things like this:

    File `./configure' updated
    File `./gdb/configure' updated
    File `./gdb/doc/configure' updated
    File `./gdb/gdbserver/configure' updated
    File `./gdb/nlm/configure' updated

etc.  So something on your system interfered with the djconfig.sh
script.

My first guess would be that you either don't have the GNU Find
utility installed, or have a FIND.EXE program from the stock
DOS/Windows distribution on your PATH, and djconfig.sh picks it up
before the DJGPP port of GNU Find utility, which should be in your
D:\DJGPP\bin directory.  Please verify that you have find.exe in
D:\DJGPP\bin, and that D:\DJGPP\bin appears in PATH *before* C:\DOS or
C:\WINDOWS\COMMAND.
From Stephane.Carrez@worldnet.fr Fri Jun 16 13:03:00 2000
From: Stephane Carrez <Stephane.Carrez@worldnet.fr>
To: binutils@sourceware.cygnus.com, gdb@sourceware.cygnus.com, gcc@gcc.gnu.org, crossgcc@sourceware.cygnus.com
Cc: gnu-m68hc11@egroups.com
Subject: 68HC11&68HC12 port for Binutils, Gdb and Gcc
Date: Fri, 16 Jun 2000 13:03:00 -0000
Message-id: <394AA4E7.7AC79E6A@worldnet.fr>
X-SW-Source: 2000-06/msg00138.html
Content-length: 2185

Hi Binutils, Gdb, Gcc maintainers, and co,

At beginning of 1999, I've started to port the Binutils, Gdb and Gcc
for the Motorola 68HC11 and 68HC12 microcontrollers. The full port 
is completely operational for a long time now.

I took quite a lot of time to validate it, fix bugs and polish the code.
Too much time would say the ones that whished to have all this
integrated in FSF mainline source trees. However, throught this
long and slow process I've been able to make sure the port is correct
and the directions I took are the good ones.

I was also concerned by trying to limit the number of patches I will submit
to binutils, gdb and gcc mailing lists. I know that some maintainers are 
overwhelmed by patches and it was of no use to send them half working port.

But now is the time for patches.

In the following weeks, I will send a number of patches:

 - to binutils for the support of 68HC11 and 68HC12 in bfd, opcodes,
   gas and ld. This will include a validation suite for the assembler.   

 - to gdb for the 68HC11 support and for a 68HC11 simulator (with SCI, 
   SPI, eeprom, nvram, timer devices). This will include some fixes
   to the current simulator support.

 - to gcc for the 68HC11 and 68HC12 code generation including some
   fixes and a couple of improvements.

To validate the port, I ported newlib 1.8.2 and I setup some dejagnu files.
(I've obtained 46 failures on 16008 tests for gcc 2.95, and 124 failures
 on 19424 tests for gcc 2.96, CVS of June 10)

I have a letter of assignment for binutils, gdb and gcc but I have none for
newlib and dejagnu. I can still send you the patches for newlib and dejagnu
if you like. (available on the web anyway).

That's all folks, I hope you'll be prepared to receive the patches,

Thanks,
	Stephane
 
-----------------------------------------------------------------------
         Home                               Office
E-mail: stcarrez@worldnet.fr               Stephane.Carrez@sun.com
WWW:    http://home.worldnet.fr/stcarrez   http://www.sun.com
Mail:   17, rue Foucher Lepelletier        6, avenue Gustave Eiffel
        92130 Issy Les Moulineaux          78182 Saint Quentin en Yvelines
        France
From kevinb@cygnus.com Fri Jun 16 14:13:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: Stephane Carrez <Stephane.Carrez@worldnet.fr>, gdb@sourceware.cygnus.com
Subject: Re: 68HC11&68HC12 port for Binutils, Gdb and Gcc
Date: Fri, 16 Jun 2000 14:13:00 -0000
Message-id: <1000616211241.ZM27175@ocotillo.lan>
References: <394AA4E7.7AC79E6A@worldnet.fr> <Stephane.Carrez@worldnet.fr>
X-SW-Source: 2000-06/msg00139.html
Content-length: 2971

On Jun 17, 12:06am, Stephane Carrez wrote:

> Hi Binutils, Gdb, Gcc maintainers, and co,
> 
> At beginning of 1999, I've started to port the Binutils, Gdb and Gcc
> for the Motorola 68HC11 and 68HC12 microcontrollers. The full port 
> is completely operational for a long time now.

[...]

> I have a letter of assignment for binutils, gdb and gcc but I have none for
> newlib and dejagnu. I can still send you the patches for newlib and dejagnu
> if you like. (available on the web anyway).
> 
> That's all folks, I hope you'll be prepared to receive the patches,

Hi Stephane,

I looked over the gdb portions of your patches that I found at

  http://home.worldnet.fr/~stcarrez/snapshots/gdb-4.18-m68hc11-20000416.diffs.gz

Overall, the patches look good.  Some comments...

 - Send your gdb patches to gdb-patches@sourceware.cygnus.com.

 - When you send us your patches, don't include patches for ChangeLog
   comments.  Instead, prepend your ChangeLog entries to the front of
   the patch.  The person integrating your patch will put them in the
   ChangeLog just prior to committing them.

 - Don't send patches for the configure scripts (or any other files
   which are automatically generated.)  We do need patches for 
   configure.in though.  (I understand why they're in the patch on your
   web page though.)

 - It'd be best if you'd generate your patches with respect the latest
   development sources.  For gdb, information on accessing the CVS
   repository may be found at

	http://sourceware.cygnus.com/gdb/#download

   This will involve a bit of work on your part since it is quite likely
   that your 4.18 patches will not apply cleanly to the current source
   base.  However, you really are the best one to do this work since
   you are the one most familiar with your port and you also have the
   equipment to test the end result.

 - Over time, it would be best if you'd "multi-arch" your target.  This
   means that most of the stuff defined via macros in tm-m68hc11.h
   will get moved to m68hc11-tdep.c and will be defined as functions
   instead.  You will also add m68hc11_gdbarch_init() (or somesuch) to
   your tdep.c file to set up access to these functions through the
   multi-arch framework.  For examples of multi-arched code, take a
   look at d10v-tdep.c, mips-tdep.c, or ia64-tdep.c.

   I think it'd be okay though if you'd submit your code in it's
   present non-multiarched form, get it into the repository, and then
   work on multi-arching it.  (We can help you with that, but it'll be
   easier if your code is in place first.)

 - I noticed that support for calling inferior functions (all of the
   call dummy stuff) isn't finished yet.  That's okay...  but when you
   get around to it, I suggest you use the generic dummy frames
   machinery.  (You will be amazed at how much easier this is to use
   than the old mechanism.) Search for the "GENERIC DUMMY FRAMES"
   comment in blockframe.c for more information.

Kevin
From robert.lopez@abq.sc.philips.com Fri Jun 16 14:39:00 2000
From: robert.lopez@abq.sc.philips.com
To: gdb@sourceware.cygnus.com
Subject: gdb-5.0 on Solaris (SunOS 5.7)
Date: Fri, 16 Jun 2000 14:39:00 -0000
Message-id: <200006162131.PAA06484@abqn07.sca.philips.com>
X-SW-Source: 2000-06/msg00140.html
Content-length: 9913

Trying to install gdb-5.0 on Solaris
Solaris 5.7 Generic sun4m sparc
gcc version 2.95.1 19990816 (release)
GNU Make version 3.77

configure output looks normal/ok

make output:
make[1]: Entering directory `/usr/local1/bin/build/gdb-5.0/libiberty'
if [ x"no" = xyes ] && [ ! -d pic ]; then \
  mkdir pic; \
else true; fi
touch stamp-picdir
test x"no" != xyes || \
  gcc -c -DHAVE_CONFIG_H -I/usr/local1/include -I. -I./../include  -W -Wall -Wtraditional  argv.c -o pic/argv.o
gcc -c -DHAVE_CONFIG_H -I/usr/local1/include -I. -I./../include  -W -Wall -Wtraditional argv.c
In file included from argv.c:26:
../include/libiberty.h:22: parse error before `ATTRIBUTE_MALLOC'
../include/libiberty.h:22: warning: type defaults to `int' in declaration of `ATTRIBUTE_MALLOC'
../include/libiberty.h:22: warning: data definition has no type or storage class
../include/libiberty.h:31: parse error before `ATTRIBUTE_MALLOC'
../include/libiberty.h:31: warning: type defaults to `int' in declaration of `ATTRIBUTE_MALLOC'
../include/libiberty.h:31: warning: data definition has no type or storage class
../include/libiberty.h:48: parse error before `ATTRIBUTE_MALLOC'
../include/libiberty.h:48: warning: type defaults to `int' in declaration of `ATTRIBUTE_MALLOC'
../include/libiberty.h:48: warning: data definition has no type or storage class
../include/libiberty.h:65: parse error before `ATTRIBUTE_MALLOC'
../include/libiberty.h:65: warning: type defaults to `int' in declaration of `ATTRIBUTE_MALLOC'
../include/libiberty.h:65: warning: data definition has no type or storage class
../include/libiberty.h:69: parse error before `ATTRIBUTE_MALLOC'
../include/libiberty.h:69: warning: type defaults to `int' in declaration of `ATTRIBUTE_MALLOC'
../include/libiberty.h:69: warning: data definition has no type or storage class
../include/libiberty.h:120: parse error before `ATTRIBUTE_NORETURN'
../include/libiberty.h:120: warning: type defaults to `int' in declaration of `ATTRIBUTE_NORETURN'
../include/libiberty.h:120: warning: data definition has no type or storage class
In file included from argv.c:26:
../include/libiberty.h:136: parse error before `ATTRIBUTE_MALLOC'
../include/libiberty.h:136: warning: type defaults to `int' in declaration of `ATTRIBUTE_MALLOC'
../include/libiberty.h:136: warning: data definition has no type or storage class
../include/libiberty.h:147: parse error before `ATTRIBUTE_MALLOC'
../include/libiberty.h:147: warning: type defaults to `int' in declaration of `ATTRIBUTE_MALLOC'
../include/libiberty.h:147: warning: data definition has no type or storage class
../include/libiberty.h:151: parse error before `ATTRIBUTE_MALLOC'
../include/libiberty.h:151: warning: type defaults to `int' in declaration of `ATTRIBUTE_MALLOC'
../include/libiberty.h:151: warning: data definition has no type or storage class
../include/libiberty.h:155: parse error before `ATTRIBUTE_MALLOC'
../include/libiberty.h:155: warning: type defaults to `int' in declaration of `ATTRIBUTE_MALLOC'
../include/libiberty.h:155: warning: data definition has no type or storage class
../include/libiberty.h:188: parse error before `ATTRIBUTE_PRINTF_2'
../include/libiberty.h:188: warning: type defaults to `int' in declaration of `ATTRIBUTE_PRINTF_2'
../include/libiberty.h:188: warning: data definition has no type or storage class
../include/libiberty.h:194: parse error before `ATTRIBUTE_PRINTF'
../include/libiberty.h:194: warning: type defaults to `int' in declaration of `ATTRIBUTE_PRINTF'
../include/libiberty.h:194: warning: data definition has no type or storage class
make[1]: *** [argv.o] Error 1
make[1]: Leaving directory `/usr/local1/bin/build/gdb-5.0/libiberty'
make: *** [all-libiberty] Error 2


make -k results in repeats of the above each time libiberty.h is accessed.

There is one other error in the make -k output:
make[1]: *** [concat.o] Error 1
test x"no" != xyes || \
  gcc -c -DHAVE_CONFIG_H -I/usr/local1/include -I. -I./../include  -W -Wall -Wtraditional  cplus-dem.c -o pic/cplus-dem.o
gcc -c -DHAVE_CONFIG_H -I/usr/local1/include -I. -I./../include  -W -Wall -Wtraditional cplus-dem.c
In file included from cplus-dem.c:52:
../include/libiberty.h:22: parse error before `ATTRIBUTE_MALLOC'
../include/libiberty.h:22: warning: type defaults to `int' in declaration of `ATTRIBUTE_MALLOC'
../include/libiberty.h:22: warning: data definition has no type or storage class
../include/libiberty.h:31: parse error before `ATTRIBUTE_MALLOC'
../include/libiberty.h:31: warning: type defaults to `int' in declaration of `ATTRIBUTE_MALLOC'
../include/libiberty.h:31: warning: data definition has no type or storage class
../include/libiberty.h:48: parse error before `ATTRIBUTE_MALLOC'
../include/libiberty.h:48: warning: type defaults to `int' in declaration of `ATTRIBUTE_MALLOC'
../include/libiberty.h:48: warning: data definition has no type or storage class
../include/libiberty.h:65: parse error before `ATTRIBUTE_MALLOC'
../include/libiberty.h:65: warning: type defaults to `int' in declaration of `ATTRIBUTE_MALLOC'
../include/libiberty.h:65: warning: data definition has no type or storage class
../include/libiberty.h:69: parse error before `ATTRIBUTE_MALLOC'
../include/libiberty.h:69: warning: type defaults to `int' in declaration of `ATTRIBUTE_MALLOC'
../include/libiberty.h:69: warning: data definition has no type or storage class
../include/libiberty.h:120: parse error before `ATTRIBUTE_NORETURN'
../include/libiberty.h:120: warning: type defaults to `int' in declaration of `ATTRIBUTE_NORETURN'
../include/libiberty.h:120: warning: data definition has no type or storage class
In file included from cplus-dem.c:52:
../include/libiberty.h:136: parse error before `ATTRIBUTE_MALLOC'
../include/libiberty.h:136: warning: type defaults to `int' in declaration of `ATTRIBUTE_MALLOC'
../include/libiberty.h:136: warning: data definition has no type or storage class
../include/libiberty.h:147: parse error before `ATTRIBUTE_MALLOC'
../include/libiberty.h:147: warning: type defaults to `int' in declaration of `ATTRIBUTE_MALLOC'
../include/libiberty.h:147: warning: data definition has no type or storage class
../include/libiberty.h:151: parse error before `ATTRIBUTE_MALLOC'
../include/libiberty.h:151: warning: type defaults to `int' in declaration of `ATTRIBUTE_MALLOC'
../include/libiberty.h:151: warning: data definition has no type or storage class
../include/libiberty.h:155: parse error before `ATTRIBUTE_MALLOC'
../include/libiberty.h:155: warning: type defaults to `int' in declaration of `ATTRIBUTE_MALLOC'
../include/libiberty.h:155: warning: data definition has no type or storage class
../include/libiberty.h:188: parse error before `ATTRIBUTE_PRINTF_2'
../include/libiberty.h:188: warning: type defaults to `int' in declaration of `ATTRIBUTE_PRINTF_2'
../include/libiberty.h:188: warning: data definition has no type or storage class
../include/libiberty.h:194: parse error before `ATTRIBUTE_PRINTF'
../include/libiberty.h:194: warning: type defaults to `int' in declaration of `ATTRIBUTE_PRINTF'
../include/libiberty.h:194: warning: data definition has no type or storage class
cplus-dem.c:60: parse error before `ATTRIBUTE_NORETURN'
cplus-dem.c:60: warning: type defaults to `int' in declaration of `ATTRIBUTE_NORETURN'
cplus-dem.c:60: warning: data definition has no type or storage class
cplus-dem.c: In function `demangle_template_value_parm':
cplus-dem.c:1585: warning: implicit declaration of function `xmalloc'
cplus-dem.c:1585: warning: initialization makes pointer from integer without a cast
cplus-dem.c: In function `demangle_template':
cplus-dem.c:1700: warning: function `xmalloc' was previously declared within a block
cplus-dem.c:1725: warning: function `xmalloc' was previously declared within a block
cplus-dem.c:1725: warning: assignment makes pointer from integer without a cast
cplus-dem.c:1753: warning: function `xmalloc' was previously declared within a block
cplus-dem.c:1753: warning: assignment makes pointer from integer without a cast
cplus-dem.c:1799: warning: function `xmalloc' was previously declared within a block
cplus-dem.c:1799: warning: assignment makes pointer from integer without a cast
cplus-dem.c: In function `recursively_demangle':
cplus-dem.c:2601: warning: function `xmalloc' was previously declared within a block
cplus-dem.c: In function `do_hpacc_template_const_value':
cplus-dem.c:3509: parse error before `ATTRIBUTE_UNUSED'
cplus-dem.c:3509: warning: unused parameter `work'
cplus-dem.c: In function `do_hpacc_template_literal':
cplus-dem.c:3589: warning: function `xmalloc' was previously declared within a block
cplus-dem.c: In function `do_arg':
cplus-dem.c:3697: warning: function `xmalloc' was previously declared within a block
cplus-dem.c: In function `remember_type':
cplus-dem.c:3727: warning: function `xmalloc' was previously declared within a block
cplus-dem.c:3737: warning: function `xmalloc' was previously declared within a block
cplus-dem.c:3737: warning: assignment makes pointer from integer without a cast
cplus-dem.c: In function `remember_Ktype':
cplus-dem.c:3759: warning: function `xmalloc' was previously declared within a block
cplus-dem.c:3769: warning: function `xmalloc' was previously declared within a block
cplus-dem.c:3769: warning: assignment makes pointer from integer without a cast
cplus-dem.c: In function `register_Btype':
cplus-dem.c:3791: warning: function `xmalloc' was previously declared within a block
cplus-dem.c: In function `remember_Btype':
cplus-dem.c:3816: warning: function `xmalloc' was previously declared within a block
cplus-dem.c:3816: warning: assignment makes pointer from integer without a cast
cplus-dem.c: In function `string_need':
cplus-dem.c:4245: warning: function `xmalloc' was previously declared within a block
cplus-dem.c:4245: warning: assignment makes pointer from integer without a cast
make[1]: *** [cplus-dem.o] Error 1

Suggestions?

-Robert Lopez
From nsd@redhat.com Fri Jun 16 14:55:00 2000
From: Nick Duffek <nsd@redhat.com>
To: gdb@sourceware.cygnus.com
Subject: Re: non-blocking reads/writes and event loops
Date: Fri, 16 Jun 2000 14:55:00 -0000
Message-id: <200006162154.RAA21307@nog.bosbc.com>
References: <3944B786.A16E9A2F@cygnus.com>
X-SW-Source: 2000-06/msg00141.html
Content-length: 1771

On 12-Jun-2000, Andrew Cagney wrote:

>Should GDB continue to be pushed to the point
>where everything is event based or should, the current compromise remain
>where a GUI is unable to exploit GDBs event-loop.

On 12-Jun-2000, Jim Ingham wrote:

>One thing to remember about this is that any blocking operation that can
>fail, particularly ones that have fairly long timeouts (or in some cases
>like the RDI code, none at all) becomes a point of fragility for any GUI
>based on top of gdb.

[...]

>So my vote is to eradicate ALL the blocking behavior, and make GDB a pure
>event driven application.

Does that include file I/O?  Reading a core file over NFS could freeze a
GUI for quite a while.

If so, then we'd need to invert BFD as well.

I'd rather see the GUI problems solved by two processes:
  (1) the GDB core, which talks to inferior processes;
  (2) the user interface, which talks to (1) over a pipe using a
      well-defined protocol.

[Credit to Chris Faylor and Jim Blandy for suggesting this approach.]

The user interface could be a GUI, a command-line interface, Emacs, etc.
Pipes are non-blocking, so a GUI need never freeze due to blocking
debugging calls.

As far as I can tell, this provides all the benefits of fully
event-loopizing GDB without the cost of making GDB hugely more complex.

Toward implementing this approach, it might be helpful to have a library
for storing and transferring parts of GDB state like breakpoints,
watchpoints, and "set" values.

Such a library could be used by a GUI e.g. to maintain a copy of the
breakpoint list, so that it could perform the equivalent of "info
breakpoints" without blocking.

It could also be used to implement the saving of breakpoints, watchpoints,
and other state across GDB sessions.

Nick
From ac131313@cygnus.com Sun Jun 18 21:33:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: UI_OUT as default?
Date: Sun, 18 Jun 2000 21:33:00 -0000
Message-id: <394DA268.6FC59235@cygnus.com>
References: <3947A37B.6EA3C81C@cygnus.com>
X-SW-Source: 2000-06/msg00142.html
Content-length: 442

Fernando Nasser wrote:
> 
> Now that 5.0 is out, isn't it time to make UI_OUT on by default?
> This would be a first step in getting rid of the old code (and all
> those ifdefs).

Almost,

Should probably first have a a bit if a discussion on its merits.  While
the code has been sitting in the trunk for some time I'm pretty sure few
have looked at it.

Remember, it does mean a significant change in the way people output
results.

	Andrew
From ac131313@cygnus.com Sun Jun 18 22:02:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Nick Duffek <nsd@redhat.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: non-blocking reads/writes and event loops
Date: Sun, 18 Jun 2000 22:02:00 -0000
Message-id: <394DA914.5C6CA062@cygnus.com>
References: <3944B786.A16E9A2F@cygnus.com> <200006162154.RAA21307@nog.bosbc.com>
X-SW-Source: 2000-06/msg00143.html
Content-length: 1709

Nick Duffek wrote:

> >So my vote is to eradicate ALL the blocking behavior, and make GDB a pure
> >event driven application.
> 
> Does that include file I/O?  Reading a core file over NFS could freeze a
> GUI for quite a while.

Some how, I suspect not.  Some operations, such as reading/writing an
executable will continue to be blocking.  If an NFS partition freezes
then I suspect a hung GDB is the last thing on the users mind :-)

> I'd rather see the GUI problems solved by two processes:
>   (1) the GDB core, which talks to inferior processes;
>   (2) the user interface, which talks to (1) over a pipe using a
>       well-defined protocol.
> 
> [Credit to Chris Faylor and Jim Blandy for suggesting this approach.]

FYI, the ``well defined protocol'' is called MI :-)

> The user interface could be a GUI, a command-line interface, Emacs, etc.
> Pipes are non-blocking, so a GUI need never freeze due to blocking
> debugging calls.
> 
> As far as I can tell, this provides all the benefits of fully
> event-loopizing GDB without the cost of making GDB hugely more complex.

Unfortunately, it avoids rather than solves the problem.  One thing we
found from MI is that even after you separate out the GUI, GDB, in the
end, still needs to be 100% non blocking.  

Consider a GDBng (GDB 6) that is trying to talk to two (or more) active
remote targets.  The current remote.c blocks out all other activity
while it is communicating with a single target.  Just like it can
currently block out the GUI, it would also block out the processing of
those other targets.  While the user is surprisingly tolerant of a 5-30
second hiccup, the typical protocol tends to be be surprisingly
intolerant :-)

	Andrew
From ac131313@cygnus.com Sun Jun 18 22:21:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Todd Whitesel <toddpw@windriver.com>
Cc: Jim Ingham <jingham@apple.com>, gdb@sourceware.cygnus.com, "Insight (GDB GUI)" <insight@sourceware.cygnus.com>
Subject: Re: non-blocking reads/writes and event loops
Date: Sun, 18 Jun 2000 22:21:00 -0000
Message-id: <394DAD8D.C100E36F@cygnus.com>
References: <200006150149.SAA00358@alabama.wrs.com>
X-SW-Source: 2000-06/msg00144.html
Content-length: 1964

Todd Whitesel wrote:
> 
> > > Agreed. If the API designers are dumb enough to trust threads absolutely,
> > > and don't give us an option, then well, that's life.
> >
> > For what it is worth, here is the ``It is hard'' reason number two:
> ...
> > Just making certain that your eyes are open :-)
> 
> No doubts about that. That's why I said "long term goal"...

Unfortunatly, unless feasible intermediate steps are identifed that show
how we can get from the eixsting GDB to this ``long term goal'' it will
just remain a long term goal :-(

To that end, I can see several strategies.  Interestingly at least one
discards the assumption that the event loop should _not_ be re-entrant.

o	invert the targets first
		
	This would be implemented
	using something like:

	(gdb) ->do-command
	  -> target_xfer_memory()
	    -> target->request_data()
	    while need more data, run inner event loop
	       <- target-supply-data()
	    <- return data

	That is, the GDB core would continue
	to assume that things are blocking
	but the targets would internally
	be implemented as non-blocking.

	Care would be needed that the internal
	event loop didn't re-call the CLI et.al.


o	invert the expression evaluator first

	In this case, legacy targets would
	be wrapped so that:

	(gdb) ->do-command
	   -> target_memory_request()
	     -> target_xfer_memory ()
	     schedule event to supply
	     returned data to expression evaluator
	-> supply_data to expression evaluator


(wonder if this makes any sense).  Of course there is option three, both
of the above.

For what its worth, for some reason I have preference for the first
option - not sure why, perhaphs it is simply that I'm more familar with
targets and back-ends.

As I noted above, one of the original design decisions for the event
loop that it not be re-entrant.  The above questions that decision. 
Another decision was that GDB's core assume no threads.  Should that too
be questioned?

enjoy,
	Andrew
From dan@cgsoftware.com Sun Jun 18 22:46:00 2000
From: Daniel Berlin <dan@cgsoftware.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Todd Whitesel <toddpw@windriver.com>, Jim Ingham <jingham@apple.com>, gdb@sourceware.cygnus.com, "Insight (GDB GUI)" <insight@sourceware.cygnus.com>
Subject: Re: non-blocking reads/writes and event loops
Date: Sun, 18 Jun 2000 22:46:00 -0000
Message-id: <Pine.LNX.4.10.10006182227270.24967-100000@propylaea.anduin.com>
References: <394DAD8D.C100E36F@cygnus.com>
X-SW-Source: 2000-06/msg00145.html
Content-length: 3219

> Todd Whitesel wrote:
> > 
> > > > Agreed. If the API designers are dumb enough to trust threads absolutely,
> > > > and don't give us an option, then well, that's life.
> > >
> > > For what it is worth, here is the ``It is hard'' reason number two:
> > ...
> > > Just making certain that your eyes are open :-)
> > 
> > No doubts about that. That's why I said "long term goal"...
> 
> Unfortunatly, unless feasible intermediate steps are identifed that show
> how we can get from the eixsting GDB to this ``long term goal'' it will
> just remain a long term goal :-(

Almost as if planning something large was an integral part of getting it
done.
Strange.

> 
> To that end, I can see several strategies.  Interestingly at least one
> discards the assumption that the event loop should _not_ be re-entrant.
> 
> o	invert the targets first
> 		
> 	This would be implemented
> 	using something like:
> 
> 	(gdb) ->do-command
> 	  -> target_xfer_memory()
> 	    -> target->request_data()
> 	    while need more data, run inner event loop
> 	       <- target-supply-data()
> 	    <- return data
> 
> 	That is, the GDB core would continue
> 	to assume that things are blocking
> 	but the targets would internally
> 	be implemented as non-blocking.
> 
> 	Care would be needed that the internal
> 	event loop didn't re-call the CLI et.al.
> 
> 
> o	invert the expression evaluator first
> 
> 	In this case, legacy targets would
> 	be wrapped so that:
> 
> 	(gdb) ->do-command
> 	   -> target_memory_request()
> 	     -> target_xfer_memory ()
> 	     schedule event to supply
> 	     returned data to expression evaluator
> 	-> supply_data to expression evaluator
> 
> 
> (wonder if this makes any sense).  Of course there is option three, both
> of the above.
> 
> For what its worth, for some reason I have preference for the first
> option - not sure why, perhaphs it is simply that I'm more familar with
> targets and back-ends.
> 

> As I noted above, one of the original design decisions for the event
> loop that it not be re-entrant.  The above questions that decision. 
And rightfully questions it, IMHO.

> Another decision was that GDB's core assume no threads.  Should that too
> be questioned?

I have no problem with using threads, i do it on a daily basis. The only
issue i would have with GDB's core using threads would be that we take
care not to assume that everyone has pthreads. If we go with threads, i
would ask we add a simple abstraction, like most portable things using
threads (Just from personal experience, Python's source comes to mind as 
something that works with threads, using "easy to make work on a given
platform supporting threads", and provides all the thread functionality
people ask for. Works on BeOS, QNX, and every other python 
supported platform that has threads).

The question about whether we *should* use threads is a different one
altogether.
The real question splits into "Are there parts of gdb where we could be
doing
processing that isn't dependent on other processing, and we therefore are
possibly wasting time on MP systems by not having each done in a thread"
and "Are there parts of GDB where we could simplify code flow by using
threads".

 >
> enjoy, > Andrew >