From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128104 invoked by alias); 17 Jan 2016 16:12:52 -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 128083 invoked by uid 89); 17 Jan 2016 16:12:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=leverage, baked, traces, sk:zeroin X-Spam-User: qpsmtpd, 2 recipients X-HELO: smtp.gentoo.org Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Sun, 17 Jan 2016 16:12:50 +0000 Received: from vapier.lan (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with SMTP id B88CE340B6E; Sun, 17 Jan 2016 16:12:47 +0000 (UTC) Date: Sun, 17 Jan 2016 16:12:00 -0000 From: Mike Frysinger To: Joel Brobecker Cc: Michael Frysinger , gdb-patches@sourceware.org, Olivier Hainque Subject: Re: new sim: Visium Message-ID: <20160117161247.GM4894@vapier.lan> Mail-Followup-To: Joel Brobecker , Michael Frysinger , gdb-patches@sourceware.org, Olivier Hainque References: <20160106044754.GC23304@adacore.com> <20160106193601.GR25548@vapier.lan> <20160107033505.GA4505@adacore.com> <20160107055330.GV25548@vapier.lan> <20160117092446.GE4059@adacore.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wXC5D88JtmMokAwr" Content-Disposition: inline In-Reply-To: <20160117092446.GE4059@adacore.com> X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg00353.txt.bz2 --wXC5D88JtmMokAwr Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 4556 On 17 Jan 2016 13:24, Joel Brobecker wrote: > > > > this looks hairy and will require a good bit of unwinding. you sho= uldn't > > > > be defining your own sim_read/sim_write anymore. if you want memor= y, you > > > > should be using the common memory functions to attach it. if you w= ant to > > > > simulate hardware, you should be using the WITH_HW framework. > > >=20 > > > For the read/write functions, we have a feature read-before-write > > > feature which I don't think the current sim provides. > >=20 > > i don't know what this feature is. could you elaborate ? >=20 > 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. >=20 > I think this is a debugging aid, to detect access to uninitialized > memory. this sounds like a useful feature we can add to the common core :) > > > 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? > >=20 > > when you attach memory, the default is to be zero filled. we do this > > for all ports. that sounds pretty reliable to me :). > >=20 > > if you want to use a diff value, you can do this from the command line: > > $ run --memory-fill 0xff --memory-size 10Mb ... > >=20 > > did you need something else ? >=20 > 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 default should be the same across architectures imo, and that default today is zero-filled memory. having a configure flag might be useful, but i'm not sure how many people would actually leverage it. especially when there are flags already (that i showed above) that do what they want. to clarify some background in case it helps: i see the simulator core as a bunch of generic building blocks. the arch port itself only adds support for the ISA (insns & registers) to the equation. once you get beyond that (e.g. the memory or devices), now you're talking about more building blocks than stuff that should be baked in/architecture defaults. so even if today all of the systems that have a visium cpu also initialize the system mem in a specific way, the visium arch core should not be doing any of that. this makes it very easy to take just the visium ISA and construct a new cpu from scratch that has new/different behavior and play around with things. when you do want behavior that matches an existing board, that's where the model framework comes into play. you can define specific cpu/system combinations that match existing products and users can pick those via the --model flag. does that make sense ? > 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. this can easily be dangerous when you write asm code, but i feel like this doesn't translate (that much) across to C code. static/uninitialized vars (i.e. bss) are required to be zero-initialized. people often run into trouble with uninitialized stack values, but you'd get same behavior there i think in the sim today as you would on a real system. > > 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 ? >=20 > 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. i've started a wiki page here: https://sourceware.org/gdb/wiki/Sim/TODO feel free to add a bullet point there with sub points that outline your requirements. -mike --wXC5D88JtmMokAwr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWm71/AAoJEEFjO5/oN/WBJ00P/iHAAU5iEYxgsYfZMqosgmYM 0NPmotcntDbyYRqsZtNxZjTLH+gZnRqbdonQmSuE5bjrTk+G+zYwZprT/Q7cOSAi IxVSO2Yc6OwgeXoy207rVvhKkQW8V29wV5tDmCOwqLAMDZBn83K0xYz5Qa0Bg8go Sla3yiskEqcEhgJHGYnVJ8T5ZRRJJ5IBDvE8tgq3xdbMTBlqr6YETMuOiGfsFgby fy4ARCaFP6iEGwZ6Ecv1wbTTK4NMKdzmbZ8P3bs+r/QeE5neas8iQWM9Px5Jv6j5 prCgTo41p3RDC9WJigpnJOdVQ2PrsChL8qs8QYGl6B3h8kYAu6brSz1K30BZFx9y M72ArK28xXDIrJmmVGyRnkpNzydFZ8u3rarEJ4wrGtElN8pwMu1M1xC2kdgB/kA4 50VkjxQ2zIf0oQMtUCwUgZoZneets17Fs/67RZCALuZ1E+TbWgrYdLbsV0MFgT0m 0WRgs68raNzsMbPB13abwSVXNJxfiFNXIkQ5tgvtY2E2IVVD7vSHiqOWpOuDz5QE QmmkWKc1IG9lw3dQjCsaERF1y0ZhGjY+915BXU2QOKANKd03KoPNfLrSaJmMga7d ntwI2m6PnwXSv8LGEphBVWd4U8MEcOQokG0mNP4Im8gLcYKLi6bnVQ6keo28Nxjn /OX4aQqwxiQwoXooBPmi =iyT+ -----END PGP SIGNATURE----- --wXC5D88JtmMokAwr--