From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28629 invoked by alias); 16 Jan 2004 05:56:53 -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 28418 invoked from network); 16 Jan 2004 05:56:46 -0000 Received: from unknown (HELO mail01.idc.renesas.com) (202.234.163.13) by sources.redhat.com with SMTP; 16 Jan 2004 05:56:46 -0000 Received: (from root@localhost) by guardian02.idc.renesas.com with id i0G5ufxh023380; Fri, 16 Jan 2004 14:56:41 +0900 (JST) Received: from unknown [172.20.8.71] by guardian02.idc.renesas.com with SMTP id QAA23379 ; Fri, 16 Jan 2004 14:56:40 +0900 Received: from dnma02 (dnma02.rso.renesas.com [10.15.11.200]) by dnma01.rso.renesas.com (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HRK00CIHJ6H3B@dnma01.rso.renesas.com>; Fri, 16 Jan 2004 14:56:41 +0900 (JST) Received: from t1pcapricot.tool.maec.co.jp ([10.145.105.37]) by dnma02.rso.renesas.com (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with SMTP id <0HRK003BVJ6GTG@dnma02.rso.renesas.com>; Fri, 16 Jan 2004 14:56:40 +0900 (JST) Date: Fri, 16 Jan 2004 05:56:00 -0000 From: Kazuhiro Inaoka Subject: Re: [PATCH] fix trap in parallel for m32r-sim To: Doug Evans Cc: Andrew Cagney , gdb-patches@sources.redhat.com Message-id: <006d01c3dbf6$5edebfc0$2569910a@tool.maec.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-transfer-encoding: 7BIT References: <005301c3dbe1$6352c840$2569910a@tool.maec.co.jp> <16391.23988.251985.754761@claire.transmeta.com> X-SW-Source: 2004-01/txt/msg00407.txt.bz2 > There's no documentation here that indicates why things are being > done the way they are. > If it were my call, I would require more comments. > i.e. _why_ is "trap || insn" being treated as "insn -> trap". > This seems like an erroneous thing to do at first glance, > ergo the need for comments explaining why things are the way they are. > Does h/w really work that way? The sequence is the same. If insn changes SM, IE or C flag, trap will be store wrong value. (rare case?) When you use "trap || insn", m32r_trap() is executed before executed insn. A m32r_trap() uses a result of insn. ex) trap #2 || ldi r7,#1 What want to do is to execute m32r_trap() after second insn. > Also, if things are indeed kosher, why the added FIXMEs? It's meaning this patch is not enough to fix it. I think it is a first step. Kazuhiro