From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: jtc@redback.com Cc: gdb@sourceware.cygnus.com Subject: Re: dcache Date: Fri, 16 Jun 2000 02:26:00 -0000 Message-id: <3949F298.E645CD9E@cygnus.com> References: <5mem5y1rj2.fsf@jtc.redback.com> X-SW-Source: 2000-06/msg00136.html "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 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" > 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 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 To: Stephane Carrez , 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> 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 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 To: Fernando Nasser 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 To: Nick Duffek 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 To: Todd Whitesel Cc: Jim Ingham , gdb@sourceware.cygnus.com, "Insight (GDB GUI)" 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 To: Andrew Cagney Cc: Todd Whitesel , Jim Ingham , gdb@sourceware.cygnus.com, "Insight (GDB GUI)" Subject: Re: non-blocking reads/writes and event loops Date: Sun, 18 Jun 2000 22:46:00 -0000 Message-id: 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 >