From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19297 invoked by alias); 19 Mar 2004 19:59:23 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 19287 invoked from network); 19 Mar 2004 19:59:22 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 19 Mar 2004 19:59:22 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 649562B92; Fri, 19 Mar 2004 14:59:20 -0500 (EST) Message-ID: <405B5118.4050009@gnu.org> Date: Fri, 19 Mar 2004 19:59:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: David Carlton Cc: gdb-patches@sources.redhat.com Subject: Re: [patch/rfc] Add meaningful section titles to PROBLEMS References: <405B1CE3.2070007@gnu.org> <405B2EF0.6050009@gnu.org> In-Reply-To: Content-Type: multipart/mixed; boundary="------------000100070005000904030407" X-SW-Source: 2004-03/txt/msg00470.txt.bz2 This is a multi-part message in MIME format. --------------000100070005000904030407 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1794 >>> As for some of the others, I think they would be better served as >>> notes in the documentation (i.e., gdb.texinfo). > > > That's a good point - if we want to make users aware of certain > well-known bugs, then gdb.texinfo is a much more visible place than > PROBLEMS. (Nobody will see PROBLEMS other than possibly the specific > individual, if any, who is installing that version of GDB by hand.) > GCC has a section of known bugs in its manual; we should follow suit. Right, now we're getting somewhere. I've attached the original PROBLEMS file from 5.1. Looking through the file it's pretty clear what the [my] original intent was - late breaking stuff-ups. It strongly suggests using the same criteria as the release process: "doesn't build, break main; run doesn't work" however, also including: "problems instead fixed in mainline" would be a good get-out-of goal free card. A list of "medium"(1) !change-request "bugs" would be easy to generate. Properly @anchor{}ed it could even be cross referenced from the main text (but lets walk before we can run). That could be included in the doco as an appendix. >>>>> Personally, the old division makes more sense to me: a list of all >>>>> regressions, plus some more serious outstanding issues. Obviously the >>>>> header "Regressions since 5.3" should be changed, however. > > >>> How about: serious problems that have been fixed in the mainline but >>> are too nasty to backport? > > > The "breakpoints in constructors" bug isn't fixed in mainline, > either. (it's actually the GDB doesn't support N:M breakpoints bug but that's another story :-) It should be in the doco. Andrew (1) "high" gets used by me when doing a release process. Everyone knows that "low" translates to "won't fix" right ;-) --------------000100070005000904030407 Content-Type: text/plain; name="PROBLEMS" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="PROBLEMS" Content-length: 1426 Known problems in GDB 5.1.1 See also the bug database http://www.gnu.org/software/gdb/bugs/ Contrary to the GDB 5.1.1 announcement, the update did not contain fixes to a i386 floating point problem. The latest sources do contain the fix and it will be included in GDB 5.2. Known problems in GDB 5.1 hppa2.0-hp-hpux10.20 Due to a problem (conflicting types) with libiberty/regex.c, GDB 5.1 does not build on HP/UX 10.20 when using the HP supplied compiler. Due to bit rot, GDB 5.1 does not work on HP/UX 10.20 when built with GCC. hppa2.0w-hp-hpux11.00 Due to a problem with ltconfig and long argument lines, GDB 5.1 does not configure on HP/UX 11.00. alpha-dec-osf5.1 GDB 5.1 has a number of problems on this platform (Ref PR gdb/237). A GDB 5.1 built with ``CC="cc -DUSE_LDR_ROUTINES"'' is reported to work much better. alpha-dec-osf4.0e GDB 5.1 is known to have problems on this platform (encounters an internal error in the symbol table reader). sparcv9-sun-solaris2.8 There are known problems with building GDB 5.1 using GCC 3.0.x for the 64 bit SPARC target (bad code gen). You could try a development version of GCC. i586-sco-sysv5uw7.1.1 There are known problems with GDB 5.1's thread support on this platform. Non-threaded programs should work. *-*-* GDB 5.1 assumes that the host C compiler implemends alloca(). GCC is one such compiler. This problem should be fixed on the trunk. --------------000100070005000904030407--