From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Philippe De Muyter" To: eliz@is.elta.co.il Cc: ezannoni@cygnus.com, ac131313@cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: HAVE_POLL is not enough - RFA Date: Sat, 18 Mar 2000 15:00:00 -0000 Message-id: <200003182300.AAA32279@mail.macqel.be> References: <200003182226.RAA07052@indy.delorie.com> X-SW-Source: 2000-03/msg00336.html Eli Zaretskii wrote : > * event-loop.c (top-level) [NO_FD_SET]: Deprecate this branch. > Print an error at compile time if we are to use select, but FD_SET > is not available. > (SELECT_MASK, NBBY, FD_SETSIZE, NFDBITS, MASK_SIZE): Define only > if HAVE_POLL is not defined and NO_FD_SET *is* defined. > (create_file_handler) [!HAVE_POLL]: Use FD_SET and FD_CLR. > (delete_file_handler) [!HAVE_POLL]: Use FD_CLR and FD_ISSET. > (gdb_wait_for_event) [!HAVE_POLL]: Copy fd_set sets directly > instead of using memcpy and memset. Use FD_ISSET. > > +#ifdef NO_FD_SET > +/* All this stuff below is not required if select is used as God(tm) > + intended, with the FD_* macros. Are there any implementations of > + select which don't have FD_SET and other standard FD_* macros? I > + don't think there are, but if I'm wrong, we need to catch them. */ > +#error FD_SET must be defined if select function is to be used! I agree completely that your change is the right thing, but it misses the following sequence : #if HAVE_SYS_SELECT_H #include #endif that is needed a.o. on AIX (See e.g. the sources of bash, screen, mc, uucp, ncurses, inetutils, cvs or emacs) Philippe >From cgf@cygnus.com Sat Mar 18 16:40:00 2000 From: Chris Faylor To: Eli Zaretskii Cc: kettenis@wins.uva.nl, kevinb@cygnus.com, jimb@cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: Linux sigtramp detection code moved to its proper place Date: Sat, 18 Mar 2000 16:40:00 -0000 Message-id: <20000318194001.B1270@cygnus.com> References: <200003162241.RAA19616@zwingli.cygnus.com> <1000316225504.ZM3009@ocotillo.lan> <20000316180048.A30640@cygnus.com> <200003162311.e2GNBUH00362@delius.kettenis.local> <20000316193609.D30640@cygnus.com> <200003182227.RAA07055@indy.delorie.com> X-SW-Source: 2000-03/msg00337.html Content-length: 1666 On Sat, Mar 18, 2000 at 05:27:17PM -0500, Eli Zaretskii wrote: > >> I would be in favor of just creating an i386-linux-tdep.c and working >> out the 8.3 issues later. Since there are already 8.3 issues in >> the gdb source directory, adding one more is not going to aggravate >> the problem unduly. > >I beg to disagree ;-). Let me explain why. > >What I intend to do to resolve the problem of file names clashing in >the 8+3 namespace is to use the feature of DJTAR, an untar utility >which comes with DJGPP, to rename files on the fly. To this end, I >created a name-mapping file which specifies what files to rename and >how; this file needs to be submitted to DJTAR when unpacking the >distribution. I will make the file itself part of the distribution >(so DJGPP users will need to unpack that special file first, and then >the rest). > >I already spent a frustrating evening creating this name-mapping file; >adding any new files that clash with existing files would require me >to reproduce that file, possibly affecting other files as well. > >I respect the decision not to change any names before GDB 5.0 is >released, but in the meantime could we please not add any new files >whose names clash? I am sympathetic to the plight of DOS users but this sounds like it is something that could, in the short term, be handled by a program or perl script fairly easily. If you actually have a solution for DOS, then maybe that file or script should be part of the distribution and we should not have to worry about this severe filename limitation. IMO, in the long-term intelligent use of subdirectories should reduce the size of all of the filenames. cgf >From kevinb@cygnus.com Sat Mar 18 23:21:00 2000 From: Kevin Buettner To: gdb-patches@sourceware.cygnus.com Subject: [PATCH RFA] Another utils.c patch Date: Sat, 18 Mar 2000 23:21:00 -0000 Message-id: <1000319072047.ZM14883@ocotillo.lan> X-SW-Source: 2000-03/msg00338.html Content-length: 1006 This fixes another bug uncovered by running the testsuite for the IA-64... may I check this one in? * utils.c (floatformat_from_doublest): Make sure space that we're writing the float to is completely initialized to zeroes, even when the number of bits in the float is not evenly divisible by FLOATFORMAT_CHAR_BIT. Index: utils.c =================================================================== RCS file: /cvs/src/src/gdb/utils.c,v retrieving revision 1.4 diff -u -p -r1.4 utils.c --- utils.c 2000/03/04 02:23:06 1.4 +++ utils.c 2000/03/19 07:12:00 @@ -2722,7 +2722,8 @@ floatformat_from_doublest (fmt, from, to unsigned char *uto = (unsigned char *) to; memcpy (&dfrom, from, sizeof (dfrom)); - memset (uto, 0, fmt->totalsize / FLOATFORMAT_CHAR_BIT); + memset (uto, 0, fmt->totalsize / FLOATFORMAT_CHAR_BIT + + ((fmt->totalsize % FLOATFORMAT_CHAR_BIT) == 0 ? 0 : 1)); if (dfrom == 0) return; /* Result is zero */ if (dfrom != dfrom) /* Result is NaN */