From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Kettenis To: blizzard@redhat.com Cc: kevinb@cygnus.com, gdb@sourceware.cygnus.com Subject: Re: Linux threads support Date: Wed, 30 Aug 2000 00:07:00 -0000 Message-id: <200008300706.e7U76ph00984@delius.kettenis.local> References: <200008271535.e7RFZZc04890@delius.kettenis.local> <1000827160616.ZM14856@ocotillo.lan> <39AC77FE.3040708@redhat.com> X-SW-Source: 2000-08/msg00161.html Date: Tue, 29 Aug 2000 22:57:02 -0400 From: Christopher Blizzard I'm not an expert on gdb but I can say from experience is that if you don't check it in where people have to fall all over themselves to not use it, it won't get tested. OK, if I don't hear any objections soon, I'll check the stuff in this weekend. Mark >From ac131313@cygnus.com Wed Aug 30 01:16:00 2000 From: Andrew Cagney To: Stan Shebs Cc: gdb@sources.redhat.com Subject: Re: Switching to the Lesser GPL Date: Wed, 30 Aug 2000 01:16:00 -0000 Message-id: <39ACC1AB.6C40AE63@cygnus.com> References: <39AC66CE.97B04D5F@apple.com> X-SW-Source: 2000-08/msg00162.html Content-length: 1210 Stan Shebs wrote: > mmalloc is straightforward; the only consideration might be > whether we ought to convert it to GPL, much as readline has > been switched from LGPL to GPL (go to gnu.org licensing pages > for the whole story). Done deal. I've personally no opinion on what the licence should be changed to. If the trend is GPL then, it can follow. > libiberty seems like it should stay LGPL; the main trick here > is to coordinate with GCC, since all the "GNU Library..." strings > in source files change to "GNU Lesser...", thus most files will > be touched. Co-ordinate or pass the buck? :-) I think the group that should decide LIBIBERTY's licence is BINUTILS/BFD. It will affect them the most. However, I suspect that they would appreciate any help in walking any changes through the GCC source tree (which contains much of the official libiberty) and thence to binutils/gdb. > sim/ppc is entirely GPL, except for one little file words.h. > If Andrew is agreeable, I suggest making it GPL too, and dropping > the LGPL from that dir entirely. FYI, I started out having PSIM LGPL but then changed my mind. It would appear that I never got around to fixing words.h. It can be changed. Andrew >From dj@delorie.com Wed Aug 30 05:45:00 2000 From: DJ Delorie To: gdb@sourceware.cygnus.com Subject: Re: Switching to the Lesser GPL Date: Wed, 30 Aug 2000 05:45:00 -0000 Message-id: <39ACFF5D.B7AF8B21@delorie.com> References: <39AC66CE.97B04D5F@apple.com> <39ACC1AB.6C40AE63@cygnus.com> X-SW-Source: 2000-08/msg00163.html Content-length: 607 Andrew Cagney wrote: > > libiberty seems like it should stay LGPL; the main trick here > > is to coordinate with GCC, since all the "GNU Library..." strings > > in source files change to "GNU Lesser...", thus most files will > > be touched. > > Co-ordinate or pass the buck? :-) You may pass me the buck, as long as a patch is attached to it ;-) I agree it should remain LGPL; changing a license is a much bigger problem than changing the wording of an existing license. If you think it should be GPL, start a separate discussion on the gcc, gdb, cygwin, newlib, and binutils mailing lists. >From mark@acceleratednetworks.com Wed Aug 30 12:29:00 2000 From: Mark De Lange To: "Gdb Mailing List (E-mail)" Subject: GDB 5.0 and vxworks and NT Date: Wed, 30 Aug 2000 12:29:00 -0000 Message-id: X-SW-Source: 2000-08/msg00164.html Content-length: 108 Is there anyone out there who has this combination working? I'd appreciate any info if you do. Thanks Mark >From sbjohnson@ozemail.com.au Wed Aug 30 21:40:00 2000 From: Steven Johnson To: gdb@sources.redhat.com Subject: Re: Register Cache. Date: Wed, 30 Aug 2000 21:40:00 -0000 Message-id: <39ADDEAC.38565673@ozemail.com.au> References: <8AE4B526B977D411841F00A0CC334020052C28@cuz-exchange.sdesigns.net> <39AC598A.DFAF67E9@ozemail.com.au> X-SW-Source: 2000-08/msg00165.html Content-length: 932 I Want to change the way GDB Caches Registers by doing the following: 1. Add a Cache Type entry so that each register can be set (via a gdb command) to be read cached, write cached or no cache. By default it would be read/write cache enabled as is the case now. 2. Add a command to flush GDB's knowledge of the cache. My Questions are: 1. Does anyone have any input they would like to add to this? 2. What sort of command should they be maintenance, data or set commands. I Would like to have commands like this: set register-cache $r5 read set register-cache $r5 write set register-cache $r5 rw set register-cache $r5 disabled and another command maintenance register-cache flush This raises another question: 3. How do i look up the $r5 in the command and turn it into a register number? I tried finding the code the interprets: set $r5=0 to see how it did it, but it's obscure and I couldn't find it. Steven Johnson. >From micrio@mv.com Thu Aug 31 05:50:00 2000 From: "Peter Reilley" To: "Steven Johnson" , Subject: Re: Register Cache. Date: Thu, 31 Aug 2000 05:50:00 -0000 Message-id: <000c01c01349$fdc7e450$05d145cc@ppro> X-SW-Source: 2000-08/msg00166.html Content-length: 1302 Those look good to me. I would like to see a command that would set the cache state of all registers with a single command. Pete. -----Original Message----- From: Steven Johnson To: gdb@sources.redhat.com Date: Thursday, August 31, 2000 12:40 AM Subject: Re: Register Cache. >I Want to change the way GDB Caches Registers by doing the following: > >1. Add a Cache Type entry so that each register can be set (via a gdb command) >to be read cached, write cached or no cache. By default it would be read/write >cache enabled as is the case now. > >2. Add a command to flush GDB's knowledge of the cache. > >My Questions are: > >1. Does anyone have any input they would like to add to this? >2. What sort of command should they be maintenance, data or set commands. > >I Would like to have commands like this: >set register-cache $r5 read >set register-cache $r5 write >set register-cache $r5 rw >set register-cache $r5 disabled > >and another command > >maintenance register-cache flush > >This raises another question: > >3. How do i look up the $r5 in the command and turn it into a register number? > >I tried finding the code the interprets: >set $r5=0 > >to see how it did it, but it's obscure and I couldn't find it. > >Steven Johnson. >