From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2713 invoked by alias); 7 Aug 2004 04:51:46 -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 2706 invoked from network); 7 Aug 2004 04:51:45 -0000 Received: from unknown (HELO blount.mail.mindspring.net) (207.69.200.226) by sourceware.org with SMTP; 7 Aug 2004 04:51:45 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by blount.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1BtJBI-0003KM-00; Sat, 07 Aug 2004 00:51:44 -0400 Received: from mindspring.com (localhost [127.0.0.1]) by berman.michael-chastain.com (Postfix) with SMTP id 9F8F64B102; Sat, 7 Aug 2004 00:51:43 -0400 (EDT) Date: Sat, 07 Aug 2004 04:51:00 -0000 From: Michael Chastain To: gdb-patches@sources.redhat.com, eliz@gnu.org Subject: [rfa/doco] PROBLEMS: remove pr gdb/1505 Message-ID: <41145FDE.nail9GZ1WMY09@mindspring.com> User-Agent: nail 10.8 6/28/04 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-08/txt/msg00193.txt.bz2 One of the PR's in PROBLEMS has been fixed in gdb HEAD. This patch removes the PR from PROBLEMS. I'm not sure what to put in the title. Leaving it as "Known problems in GDB 6.2" is wrong. So I changed it "Known problems in GDB HEAD". Testing: not tested. Okay to commit? Michael C 2004-08-07 Michael Chastain * PROBLEMS: Update title. Remove gdb/1505. Index: PROBLEMS =================================================================== RCS file: /cvs/src/src/gdb/PROBLEMS,v retrieving revision 1.37 diff -c -3 -p -r1.37 PROBLEMS *** PROBLEMS 29 Jul 2004 22:30:31 -0000 1.37 --- PROBLEMS 7 Aug 2004 04:47:48 -0000 *************** *** 1,5 **** ! Known problems in GDB 6.2 See also: http://www.gnu.org/software/gdb/bugs/ --- 1,5 ---- ! Known problems in GDB HEAD See also: http://www.gnu.org/software/gdb/bugs/ *************** mechanism. This mechanism makes it poss *** 120,133 **** such DWARF 2 Call Frame Information (which in turn makes possible backtraces through optimized code). - Since this code is new, it is known to still have a few problems: - - gdb/1505: [regression] gdb prints a bad backtrace for a thread - - When backtracing a thread, gdb does not stop when it reaches the - outermost frame, instead continuing until it hits garbage. This is - sensitive to the operating system and thread library. - *** Threads threads/1650: manythreads.exp --- 120,125 ----