From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6806 invoked by alias); 12 Feb 2004 22:39:58 -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 6799 invoked from network); 12 Feb 2004 22:39:57 -0000 Received: from unknown (HELO smtp.uk.superh.com) (193.128.105.170) by sources.redhat.com with SMTP; 12 Feb 2004 22:39:57 -0000 Received: from sh-uk-ex01.uk.w2k.superh.com (sh-uk-ex01 [192.168.16.17]) by smtp.uk.superh.com (8.12.10/8.12.10) with ESMTP id i1CMdJAA002922; Thu, 12 Feb 2004 22:39:21 GMT Received: from linsvr1.uk.superh.com ([192.168.16.50]) by sh-uk-ex01.uk.w2k.superh.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 12 Feb 2004 22:40:49 +0000 Received: (from renneckej@localhost) by linsvr1.uk.superh.com (8.11.6/8.11.6) id i1CMdJK12072; Thu, 12 Feb 2004 22:39:19 GMT From: Joern Rennecke Message-Id: <200402122239.i1CMdJK12072@linsvr1.uk.superh.com> Subject: Re: [RFA] sh-sim loose ends To: msnyder@redhat.com (Michael Snyder) Date: Thu, 12 Feb 2004 22:39:00 -0000 Cc: amylaar@fairadsl.co.uk (Joern Rennecke), joern.rennecke@superh.com, gdb-patches@sources.redhat.com In-Reply-To: <402BF664.1060508@redhat.com> from "Michael Snyder" at Feb 12, 2004 01:55:48 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Feb 2004 22:40:49.0179 (UTC) FILETIME=[42FF7EB0:01C3F1B9] X-Scanned-By: MIMEDefang 2.39 X-SW-Source: 2004-02/txt/msg00333.txt.bz2 > * gencode.c (movt): Modifies R[n]; call 'L' macro. That doesn't make sense, 'L' simulates the data read memory latency of an SH[123]. movt doesn't incur such a latency. > (trapa): Factor out duplicate variable 'imm' (same as 'i'). OK. But I don't see why you need the cast to long. > (sleep, trapa, ppi): Use SET_NIP to modify nip. I don't see any need for this. RAISE_EXCEPTION already clears saved_state.asregs.insn_end , so that takes care of the exceptions that might arise during sleep. For trapa, that leaves just the possibility that we fail to miss a loop bound that is set to somewhere inside a profiler trap; I think you deserve whatever you get when you do that. Similar for ppi; are you afrais that we fail to miss a loop bound that is set to field_b of a ppi insn?