From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 130012 invoked by alias); 17 Jan 2016 09:24:55 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 128095 invoked by uid 89); 17 Jan 2016 09:24:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=good!, traces, bomb, simulate X-Spam-User: qpsmtpd, 2 recipients X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Sun, 17 Jan 2016 09:24:52 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 8FAB81164C4; Sun, 17 Jan 2016 04:24:50 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id tOotjIIG5hXB; Sun, 17 Jan 2016 04:24:50 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 1E1F2116471; Sun, 17 Jan 2016 04:24:50 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 161BE4080A; Sun, 17 Jan 2016 13:24:46 +0400 (RET) Date: Sun, 17 Jan 2016 09:24:00 -0000 From: Joel Brobecker To: Michael Frysinger , gdb-patches@sourceware.org, Olivier Hainque Subject: Re: new sim: Visium Message-ID: <20160117092446.GE4059@adacore.com> References: <20160106044754.GC23304@adacore.com> <20160106193601.GR25548@vapier.lan> <20160107033505.GA4505@adacore.com> <20160107055330.GV25548@vapier.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160107055330.GV25548@vapier.lan> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2016-01/txt/msg00351.txt.bz2 Hi Mike, [sorry for the late answer, crazy week...] > > I see that many of the small differences are comments and formatting, > > so I will work towards normalizing. But there seems to be an important > > difference in: > > > > const sim_fpu sim_fpu_qnan = { > > - sim_fpu_class_qnan, 0, 0, 0 > > + sim_fpu_class_qnan, 1, 1152921367167893504, 1986400654 > > > > I am not sure what to do for that one... > > > > I was hoping we could start with visium having its own copy for now, > > with the understanding that we should find a solution to avoid it > > in the future. > > is this the only difference ? iiuc, it's not unheard of for arches (either > in the hardware or the ABI) to define different values for NaN. as such, > letting a target override this makes sense. > > maybe for now introduce a define like: > #ifndef SIM_FPU_QNAN_VALUE > # define SIM_FPU_QNAN_VALUE 0, 0, 0 > #endif > const sim_fpu sim_fpu_qnan = { > sim_fpu_class_qnan, SIM_FPU_QNAN_VALUE > }; > > and then in your sim-main.h do: > #define SIM_FPU_QNAN_VALUE 1, UNSIGNED64(0xfffffe000000000), 0x7666118e > > while you're at it, use hex values to make it more readable :) That works. I also had a change to look at the differences more closely, and there are more; but I haven't really had much time to check how significant those changes actually are. I'll keep you posted, of course. > you can get to the state from the cpu: > SIM_DESC sd = CPU_STATE (cpu); > > so i don't think you need to do any structure shuffling Ah, good! I will make that change. > > > this looks hairy and will require a good bit of unwinding. you shouldn't > > > be defining your own sim_read/sim_write anymore. if you want memory, you > > > should be using the common memory functions to attach it. if you want to > > > simulate hardware, you should be using the WITH_HW framework. > > > > For the read/write functions, we have a feature read-before-write > > feature which I don't think the current sim provides. > > i don't know what this feature is. could you elaborate ? We can configure the simulator to raise a warning/error when a region of memory which hasn't been written/initialized yet is being read. I think this is a debugging aid, to detect access to uninitialized memory. > > There is > > also a pre-initialization feature of the RAM to a certain value > > to make execution more reliable when the program reads undefined > > memory. What would you suggest we do? > > when you attach memory, the default is to be zero filled. we do this > for all ports. that sounds pretty reliable to me :). > > if you want to use a diff value, you can do this from the command line: > $ run --memory-fill 0xff --memory-size 10Mb ... > > did you need something else ? I think "need" is a slight overstatement in our context, but perhaps we could have a to specify what byte value a port wants to use for pre-filling the memory? I could see a #define that to provide a common default which each sim could override for their own default; and then, if people want, a configure option to force whatever value they want, irrespective of the default chosen by the architecture. The people who first implemented this visium simulator chose 0xff, which is just as arbitrary as zero, but it just so happens that using this value made me realize, when I wrote a test, that I was making an invalid assumption, and that the test might actually bomb on me anytime. At the time, I didn't see the problem because my memory region happened to be initialized to zero, which is the assumption I was making. > currently the sim-trace module does not have output formats. i'm open > to extending this so ports can add custom hooks to control it. can you > provide a few sample lines ? would hooking at trace_generic be all you > needed ? For that part, I discussed with Olivier Hainque, who is a lot more familiar with the traces than I am; the outcome of the discussion is that it's going to be easier to separate that feature from this submission, so we'll simply ignore that part for now, because we are both a bit short on time at the moment. Thanks! -- Joel