From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8433 invoked by alias); 16 Sep 2003 17:30:40 -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 8362 invoked from network); 16 Sep 2003 17:30:38 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 16 Sep 2003 17:30:38 -0000 Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian)) id 19zJew-0007wW-2V for ; Tue, 16 Sep 2003 13:30:38 -0400 Date: Tue, 16 Sep 2003 17:30:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: SH patch 2 (was Re: [RFA] SH: Deprecate deprecated functions, use new frame interface) Message-ID: <20030916173038.GA25459@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <20030908165510.GK1859@cygbert.vinschen.de> <16226.1322.230352.450541@localhost.redhat.com> <20030915160111.GA9283@cygbert.vinschen.de> <16231.17730.828347.741094@localhost.redhat.com> <20030916172606.GU9981@cygbert.vinschen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030916172606.GU9981@cygbert.vinschen.de> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-09/txt/msg00360.txt.bz2 On Tue, Sep 16, 2003 at 07:26:06PM +0200, Corinna Vinschen wrote: > On Tue, Sep 16, 2003 at 01:15:46PM -0400, Elena Zannoni wrote: > > Corinna Vinschen writes: > > > * sh-tdep.c (struct frame_extra_info): Remove. > > > (struct sh_frame_cache): New structure. > > > [...] > > > > It looks ok, I assume that the sh64 prologue analysis is unaffected, > > right? I.e. the macros that were used for decomposing the > > instructions in sh64 case are still there, etc etc. > > Uhm... I moved the whole sh64 code to an entirely different file two > weeks ago so the one and only point of contact between sh[1-4] and sh5 > is the call of sh64_gdbarch_init() from sh_gdbarch_init(). > > All these changes don't affect sh5 at all. > > > How are the test results? Did they change? > > 54 FAILs, of which 24 are in fileio.exp which isn't supported by the sh sim. How does this compare to the old results? > > The remaining 30 FAILs are > > FAIL: gdb.base/break.exp: run until breakpoint set at small function, optimized file > FAIL: gdb.base/funcargs.exp: continue to call6k > FAIL: gdb.base/funcargs.exp: run to hitbottom > FAIL: gdb.base/huge.exp: running to main in runto > FAIL: gdb.base/huge.exp: print a very large data object > FAIL: gdb.base/interrupt.exp: send_gdb control C (timeout) > FAIL: gdb.base/interrupt.exp: call function when asleep (wrong output) > FAIL: gdb.base/interrupt.exp: echo data (timeout) > FAIL: gdb.base/scope.exp: print localval, outer scope > FAIL: gdb.base/step-test.exp: step out > FAIL: gdb.base/store.exp: print add - charest > FAIL: gdb.base/store.exp: print add - short > FAIL: gdb.base/store.exp: print old r - longest > FAIL: gdb.base/store.exp: print old r - double > FAIL: gdb.base/store.exp: print old r - doublest > FAIL: gdb.base/store.exp: up print old r - longest > FAIL: gdb.base/store.exp: up print old r - double > FAIL: gdb.base/store.exp: up print old r - doublest Hmm, with the current state of the tree those failures are pretty surprising. Especially if you turned on the dwarf2 unwinder, they shouldn't be there. > FAIL: gdb.base/structs2.exp: structs2 continue1 (PRMS 13536) > FAIL: gdb.base/structs2.exp: structs2 continue2 (PRMS 13536) > FAIL: gdb.base/watchpoint.exp: run to marker1 in test_simple_watchpoint > FAIL: gdb.base/watchpoint.exp: watchpoints found in watchpoint/breakpoint table > FAIL: gdb.base/watchpoint.exp: run to marker1 in test_disabling_watchpoints > FAIL: gdb.mi/mi-var-block.exp: create local variable foo > FAIL: gdb.mi/mi-var-block.exp: delete var foo > FAIL: gdb.mi/mi1-var-block.exp: create local variable foo > FAIL: gdb.mi/mi1-var-block.exp: delete var foo > FAIL: gdb.mi/mi2-var-block.exp: create local variable foo > FAIL: gdb.mi/mi2-var-block.exp: delete var foo > FAIL: gdb.trace/packetlen.exp: run trace experiment Some of these are GCC HEAD bugs... I think. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer