From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28501 invoked by alias); 18 Mar 2004 20:22:31 -0000 Mailing-List: contact sid-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: sid-owner@sources.redhat.com Received: (qmail 28480 invoked from network); 18 Mar 2004 20:22:30 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 18 Mar 2004 20:22:30 -0000 Received: from toenail.toronto.redhat.com (toenail.toronto.redhat.com [172.16.14.211]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 00D478000DA; Thu, 18 Mar 2004 15:22:29 -0500 (EST) Received: from toenail.toronto.redhat.com (localhost.localdomain [127.0.0.1]) by toenail.toronto.redhat.com (8.12.10/8.12.5) with ESMTP id i2IKMTHl010327; Thu, 18 Mar 2004 15:22:29 -0500 Received: (from fche@localhost) by toenail.toronto.redhat.com (8.12.10/8.12.10/Submit) id i2IKMTQH010323; Thu, 18 Mar 2004 15:22:29 -0500 X-Authentication-Warning: toenail.toronto.redhat.com: fche set sender to fche@redhat.com using -f To: Dave Brolley Cc: sid@sources.redhat.com, cgen@sources.redhat.com Subject: Re: [patch][rfa] SID --trace-semantics output References: <4059F6DD.4090407@redhat.com> From: fche@redhat.com (Frank Ch. Eigler) Date: Thu, 18 Mar 2004 20:22:00 -0000 In-Reply-To: <4059F6DD.4090407@redhat.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Reasonable Discussion) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-q1/txt/msg00041.txt.bz2 brolley wrote: > A client of ours, for whom we're developing a SID port, requested > that SID's semantic trace show the actual value stored, accounting > for read-only fields and other side effects, rather than showing the > value which was attempted to be stored. [...] Especially for bits outside the CPU, this has the potential to mislead, in that the disassembly trace would not represent the actions of the CPU. > I eventually came up with the notion that the write/set methods of > SID's busses, control registers, memory access methods and hardware > write handers could return the actual value written. [...] I am quite unfond of this approach. It is a messy and limited way of providing just one more level of tracing. Have you considered instead of all this the addition of tracing flags in the various devices that thusly mutilate their data? That way, when they detect an incoming write (from whatever source), they can print the final afterimage. With carefully arranged tracing code in cgen_cpu, the additional messages from those peripherals could appear properly intermingled. The same technique could also handle the more general cases of control registers with read side effects, or accesses that span multiple different devices. - FChE