From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Kettenis To: rth@cygnus.com Cc: bernds@masala.cygnus.co.uk, gcc-patches@gcc.gnu.org, gdb@sourceware.cygnus.com Subject: Re: More SSE infrastructure Date: Mon, 03 Jul 2000 17:20:00 -0000 Message-id: <200007040019.e640Jwe00432@delius.kettenis.local> References: <20000703122133.F25642@cygnus.com> <20000703140220.A25809@cygnus.com> X-SW-Source: 2000-07/msg00002.html Date: Mon, 3 Jul 2000 14:02:20 -0700 From: Richard Henderson [ For the GDB list, we're discussing what needs to be emitted for debug information for 128-bit integers used with SSE. Note that this is not the same as when a user has declared a proper 128-bit vector type, which is given in the debugging information as a struct, but rather to the Intel API defined __m128, which does not define the shape of the vector (float[4], int[4], short[8], ...) and so is represented as a plain int. ] Some time ago, Jim Blandy added support for SSE/SIMD to GDB[1]. We have the following definitions in gdbtypes.h: /* SIMD types. We inherit these names from GCC. */ extern struct type *builtin_type_v4sf; extern struct type *builtin_type_v4si; extern struct type *builtin_type_v8qi; extern struct type *builtin_type_v4hi; extern struct type *builtin_type_v2si; And appropriate initializations in gdbtypes.c. The "default" type for the SSE registers is builtin_type_v4sf (see config/i386/tm-i386.h:REGISTER_VIRTUAL_TYPE(N)). I don't know why (you'd have to ask Jim, but I believe he's on vacation until July 10). It would make some sense though to make the __m128 type similar to the SSE registers. If builtin_type_v4sf is indeed the most suitable return type, that would probably mean emitting the debug information as a struct. Mark [1] This work was supposed to work together with a Linux kernel patch developed by Cygnus. The stuff recenty added to Linux 2.4.0test2 is a bit different, and I'm in the process of changing GDB accordingly. If people are interested I can post a (preliminary) patch. >From ac131313@cygnus.com Tue Jul 04 01:46:00 2000 From: Andrew Cagney To: GDB Discussion Subject: GDB 5.0.1? Date: Tue, 04 Jul 2000 01:46:00 -0000 Message-id: <3961A434.262D29C7@cygnus.com> X-SW-Source: 2000-07/msg00003.html Content-length: 413 Hello, So is an incremental release worth it? Personally, I've no problems with just re-spinning the head of the 5.0 branch and calling it 5.0.1 (with the NEWS file tweeked). Beyond that, I've reservations, I'd rather see people putting more effort into the trunk and the next major release. Opinions? Give it 2-4 more weeks and then just re-spin what ever is on the head and then close the branch? Andrew >From ac131313@cygnus.com Tue Jul 04 02:02:00 2000 From: Andrew Cagney To: GDB Discussion Subject: GDB 5.1? Date: Tue, 04 Jul 2000 02:02:00 -0000 Message-id: <3961A819.7E91AE3C@cygnus.com> X-SW-Source: 2000-07/msg00004.html Content-length: 3492 (Ok, so it is Tuesday, I was ment to send this out yesterday). Now is probably the time to start to think about another GDB release. Should it occure, and if so when? What should be fixed, what would be nice to fix? I've attatched the immediatly relevant sections of the TODO file. While the TODO file contains many other potential I'd rather see the emphasis on finishing a small subset of that wish list. If others are achieved then, that is a bonus. Andrew Known problems in GDB 5.0 ========================= Below is a list of problems identified during the GDB 5.0 release cycle. People hope to have these problems fixed in a follow-on release. -- The BFD directory requires bug-fixed AUTOMAKE et.al. AUTOMAKE 1.4 incorrectly set the TEXINPUTS environment variable. It contained the full path to texinfo.tex when it should have only contained the directory. The bug has been fixed in the current AUTOMAKE sources. Automake snapshots can be found in: ftp://sourceware.cygnus.com/pub/gdb/snapshots and ftp://sourceware.cygnus.com/pub/binutils -- RFD: infrun.c: No bpstat_stop_status call after proceed over break? http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00665.html GDB misses watchpoint triggers after proceeding over a breakpoint on x86 targets. -- x86 linux GDB and SIGALRM (???) http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00803.html I know there are problems with single stepping through signal handlers. These problems were present in 4.18. They were just masked because 4.18 failed to recognize signal handlers. Fixing it is not easy, and will require changes to handle_inferior_event(), that I prefer not to make before the 5.0 release. Mark -- Revised UDP support (was: Re: [Fwd: [patch] UDP transport support]) http://sourceware.cygnus.com/ml/gdb-patches/2000-04/msg00000.html (Broken) support for GDB's remote protocol across UDP is to be included in the follow-on release. -- Can't build IRIX -> arm GDB. http://sourceware.cygnus.com/ml/gdb-patches/2000-04/msg00356.html David Whedon writes: > Now I'm building for an embedded arm target. If there is a way of turning > remote-rdi off, I couldn't find it. It looks like it gets built by default > in gdb/configure.tgt(line 58) Anyway, the build dies in > gdb/rdi-share/unixcomm.c. SERPORT1 et. al. never get defined because we > aren't one of the architectures supported. -- Problem with weak functions http://sourceware.cygnus.com/ml/gdb/2000-05/msg00060.html Dan Nicolaescu writes: > It seems that gdb-4.95.1 does not display correctly the function when > stoping in weak functions. > > It stops in a function that is defined as weak, not in the function > that is actualy run... -- GDB 5.0 doesn't work on Linux/SPARC -- Code Cleanups: Next Release =========================== The following are small cleanups that will hopefully be completed by the follow on to 5.0. -- Delete macro TARGET_BYTE_ORDER_SELECTABLE. Patches in the database. -- Purge PARAMS. Eliminate all uses of PARAMS in GDB's source code. -- Fix copyright notices. Turns out that ``1998-2000'' isn't considered valid :-( http://sourceware.cygnus.com/ml/gdb-patches/2000-05/msg00467.html -- Find something better than DEFAULT_BFD_ARCH, DEFAULT_BFD_VEC to determine the default isa/byte-order. -- Rely on BFD_BIG_ENDIAN and BFD_LITTLE_ENDIAN instead of host dependant BIG_ENDIAN and LITTLE_ENDIAN. -- >From kettenis@wins.uva.nl Tue Jul 04 02:08:00 2000 From: Mark Kettenis To: ac131313@cygnus.com Cc: gdb@sourceware.cygnus.com Subject: Re: GDB 5.0.1? Date: Tue, 04 Jul 2000 02:08:00 -0000 Message-id: <200007040908.e6498WG00704@delius.kettenis.local> References: <3961A434.262D29C7@cygnus.com> X-SW-Source: 2000-07/msg00005.html Content-length: 881 Date: Tue, 04 Jul 2000 18:45:40 +1000 From: Andrew Cagney Hello, So is an incremental release worth it? Personally, I've no problems with just re-spinning the head of the 5.0 branch and calling it 5.0.1 (with the NEWS file tweeked). Beyond that, I've reservations, I'd rather see people putting more effort into the trunk and the next major release. Opinions? Give it 2-4 more weeks and then just re-spin what ever is on the head and then close the branch? IMHO, releasing 5.0.1 is only worth the trouble if it fixes the really annoying problem with rerunning programs with breakpoints in shared libs: http://sourceware.cygnus.com/ml/gdb-patches/2000-05/msg00230.html This patch is kind of a stopgap, but I've failed to come up with something better, and no-one else seems to be interested in solving this :-(. Mark >From muller@cerbere.u-strasbg.fr Tue Jul 04 02:21:00 2000 From: Pierre Muller To: Andrew Cagney , GDB Discussion Subject: Re: GDB 5.1? Date: Tue, 04 Jul 2000 02:21:00 -0000 Message-id: <200007040921.LAA17498@cerbere.u-strasbg.fr> X-SW-Source: 2000-07/msg00006.html Content-length: 766 I just wanted to remind people that the current state for pascal language is really odd: - the language is defined (you can type "set language pascal") - default source extensions are recognized but the main part of my patch (that already is in GDB CVS tree) is not active because the new files are not compiled nor link into GDB. I sent this to gdb-patches under http://sourceware.cygnus.com/ml/gdb-patches/2000-06/msg00214.html I wanted to get reaction from people trying this out, as I am uncertain about some code parts especially in cross platform configurations. Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:muller@ics.u-strasbg.fr Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99 >From eliz@delorie.com Tue Jul 04 08:19:00 2000 From: Eli Zaretskii To: ac131313@cygnus.com Cc: gdb@sourceware.cygnus.com Subject: Re: GDB 5.1? Date: Tue, 04 Jul 2000 08:19:00 -0000 Message-id: <200007041519.LAA19774@indy.delorie.com> References: <3961A819.7E91AE3C@cygnus.com> X-SW-Source: 2000-07/msg00007.html Content-length: 470 > Date: Tue, 04 Jul 2000 19:02:17 +1000 > From: Andrew Cagney > > Now is probably the time to start to think about another GDB release. > Should it occure, and if so when? What should be fixed, what would be > nice to fix? What about rearranging the source tree so as to avoid file-name problems on 8+3 filesystems, and get rid of the ugly fnchange.lst kludge? I volunteer to suggest the new structure if people agree with making this happen. >From ac131313@cygnus.com Tue Jul 04 19:37:00 2000 From: Andrew Cagney To: Eli Zaretskii Cc: gdb@sourceware.cygnus.com Subject: Re: GDB 5.1? Date: Tue, 04 Jul 2000 19:37:00 -0000 Message-id: <39629F3A.A205EEA5@cygnus.com> References: <3961A819.7E91AE3C@cygnus.com> <200007041519.LAA19774@indy.delorie.com> X-SW-Source: 2000-07/msg00008.html Content-length: 1410 Eli Zaretskii wrote: > > > Date: Tue, 04 Jul 2000 19:02:17 +1000 > > From: Andrew Cagney > > > > Now is probably the time to start to think about another GDB release. > > Should it occure, and if so when? What should be fixed, what would be > > nice to fix? > > What about rearranging the source tree so as to avoid file-name > problems on 8+3 filesystems, and get rid of the ugly fnchange.lst > kludge? I volunteer to suggest the new structure if people agree with > making this happen. Possibly too much change :-( 5.1 is already going to see (assuming KevinB keeps up his blistering pace) an almost pure ISO-C source tree. The other big ticket items on the table is auto-make-a-fying GDB and enabling MI, I'd like to pace things a little :-) I suspect that by 5.2 (Summer 00/01 time frame (1) :-) it is going to be far clearer as to what is going to be in and what is going to be out. Things I suspect are out (to be deleted) include: config/*/xm-*.h subsumed by autoconf? config/*/tm-*.h kind of useless when all it contains is: #define GDB_MULT_ARCH 1 all the obsolete code will be gone similarly there is the question of how to correctly break down the *-tdep.c files. To address the immediate concerns, I'll get around to tweeking the build process so that it verifies fnchange.lst. Andrew (1) For the geographically challenged, I mean December-March ;-) >From rth@cygnus.com Wed Jul 05 00:16:00 2000 From: Richard Henderson To: Mark Kettenis Cc: bernds@masala.cygnus.co.uk, gcc-patches@gcc.gnu.org, gdb@sourceware.cygnus.com Subject: Re: More SSE infrastructure Date: Wed, 05 Jul 2000 00:16:00 -0000 Message-id: <20000705001646.B27048@cygnus.com> References: <20000703122133.F25642@cygnus.com> <20000703140220.A25809@cygnus.com> <200007040019.e640Jwe00432@delius.kettenis.local> X-SW-Source: 2000-07/msg00009.html Content-length: 1543 On Tue, Jul 04, 2000 at 02:19:58AM +0200, Mark Kettenis wrote: > It would make some sense though to make the __m128 type similar to the > SSE registers. I don't agree. If you wanted v4sf, you can use v4sf in the source. Though not, admittedly, with Intel's interface. But you can get it from GCC easily enough. In any case, the question at hand has absolutely nothing to do with SSE specifically, but rather what we should give GDB for describing a 128-bit integer. The GCC infrastructure currently prohibits representing full arithmetic on items larger than twice the host word size. If you take away the actual arithmetic, and just manipulate the things as data (movement and such), then the only thing left in GCC that appears to have problems is debugging. The current solution in the Cygnus tree is to force the use of long long as the `host' word size. Which slows down the compiler significantly. We're trying to figure a way out of that. So, the object being, fix the debugging code to cope with integer objects larger than twice the host word size. And in order to do that, we need to know what GDB needs to do its job. In the original message I sent, perhaps only to the GCC list (oops), I quoted a fragment from the stabs emitter, wherein we look to see if it's easy to print the upper bound for the type. If it isn't easy, we just print -1. So the question is, do we really have to print the correct upper and lower bounds for the 128-bit type, or can we just use 0 and -1, as the existing code would suggest. r~ >From gordo0678@quepasa.com Wed Jul 05 03:58:00 2000 From: To: gdb@sourceware.cygnus.com Subject: This company plans to be in Wireless Date: Wed, 05 Jul 2000 03:58:00 -0000 Message-id: <785.877911.803411@quepasa.com> X-SW-Source: 2000-07/msg00010.html Content-length: 442 Inform Worldwide, Inc. , a leader in commercial location technologies, plans to focus its proprietary GPS technologies on the Wireless Industry. ( ANYI ) Come Learn More http://www.investwise.org.uk/anyi1.html You were sent this message because your address is in our subscriber database. If you wish to be removed, please reply here; http://www.investwise.org.uk/response.html and we will remove you from our subscriber list.