From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28603 invoked by alias); 12 May 2006 20:48:58 -0000 Received: (qmail 28594 invoked by uid 22791); 12 May 2006 20:48:58 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 12 May 2006 20:48:55 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id k4CKmqla023364; Fri, 12 May 2006 22:48:52 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.6/8.13.6) with ESMTP id k4CKmqdK017990; Fri, 12 May 2006 22:48:52 +0200 (CEST) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.6/8.13.6/Submit) id k4CKmqjQ020427; Fri, 12 May 2006 22:48:52 +0200 (CEST) Date: Fri, 12 May 2006 21:34:00 -0000 Message-Id: <200605122048.k4CKmqjQ020427@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: nathanw@wasabisystems.com CC: gdb-patches@sourceware.org In-reply-to: (nathanw@wasabisystems.com) Subject: Re: Modernize NetBSD/powerpc support in GDB References: <200605021944.k42JiW6a005600@elgar.sibelius.xs4all.nl> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00264.txt.bz2 > From: "Nathan J. Williams" > Date: 11 May 2006 21:55:00 -0400 > > This seems good, though less dramatic than you report. On my macppc > system, it took the testsuite from 788 to 753 failures (though with a > notable number of PASS->FAIL changes as well) I had some PASS->FAIL changes as well; I looked at a few of them but they all seemed to be related to GDB missing a breakpoint. Presumably these breakpoints are now missed because an earlier test now PASSes and the instruction cache is in a somewhat different state now. > ; on a AMCC 440 system, it went from 179 to 170 failures, with only > one PASS->FAIL regression (which is a mysterious additional ^M in > the output of "info all-registers". Thanks for testing; I'm committing the diff then ;-). I've seen spurious ^M's in the "info all-registers" output on OpenBSD/sparc and OpenBSD/sparc64 as well. > Summary diffs attached, and I'm trying to figure out > why macppc is so much worse than the 440. My bet is still that it is a cache flushing issue, especially since the 440, which uses different code to flush the cache, is so much better.