From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22297 invoked by alias); 10 Feb 2016 07:28:48 -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 22282 invoked by uid 89); 10 Feb 2016 07:28:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=trans, reconcile, sk:virtual, uncovered 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; Wed, 10 Feb 2016 07:28:45 +0000 Received: from vapier.lan (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with SMTP id D5E3B340AF9; Wed, 10 Feb 2016 07:28:42 +0000 (UTC) Date: Wed, 10 Feb 2016 07:28:00 -0000 From: Mike Frysinger To: "Maciej W. Rozycki" Cc: Steve Ellcey , gdb-patches@sourceware.org Subject: Re: MIPS simulator is broken Message-ID: <20160210072842.GX7732@vapier.lan> Mail-Followup-To: "Maciej W. Rozycki" , Steve Ellcey , gdb-patches@sourceware.org References: <5f31ca78-325c-4c18-9abf-16de50bac964@BAMAIL02.ba.imgtec.org> <20160112010025.GE4894@vapier.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Z7VyPvL0GdI/eL50" Content-Disposition: inline In-Reply-To: X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00267.txt.bz2 --Z7VyPvL0GdI/eL50 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 3313 On 30 Jan 2016 16:09, Maciej W. Rozycki wrote: > > > mips-core: 4 byte read to unmapped address 0xffffffff80020004 at 0xff= ffffff80020004 > > > program stopped with signal 10 (User defined signal 1). > >=20 > > the mips address logic was fundamentally broken. my changes merely > > uncovered that braindeadness rather than caused it. if you look at > > that commit and the AddressTranslation definition, you'll see: > > /* For a simple (flat) memory model, we simply pass virtual > > addressess through (mostly) unchanged. */ > > vAddr &=3D 0xFFFFFFFF; > >=20 > > this is forcing all addresses to be 32-bit. when i saw this, i assumed > > it was just a dummy function someone didn't get around to finishing. >=20 > Not unreasonable unless you want to simulate gigabytes of memory (or a=20 > TLB -- does the MIPS port of sim support it?). Most programs run under=20 > sim won't need that though. There is a mistake there however, you really= =20 > want the mask to be 0x1FFFFFFF, to handle the architecture's 512MB KSEG0= =20 > and KSEG1 unmapped segments and their aliasing correctly -- some programs= =20 > rely on that. Beyond that you need some more intelligence. the sim uses a sparse memory map, so it doesn't need to fill the address space. it's pretty common for some arches to allocate maps at the top (for things like hardware) while the low addresses have the RAM. i don't know much this applies to existing mips usage. for this specific case, i don't see how the mask as implemented could ever be correct. it always threw away the top 32-bits, so when you try to use any address above 0xffffffff, it'd be silently changed to the lower 32-bits. playing with some n32 programs on a mips64 system shows that it often gets maps created both above and below that point. i don't see how chopping the top bits could possibly yield correct behavior. let me outline a few general points i think apply here: i see the simulator core as a bunch of generic building blocks. the arch p= ort 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 mips cpu also wire up the syst= em mem in a specific way, the mips arch core should not be doing any of that. this makes it very easy to take just the mips ISA and construct a new cpu f= rom 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. it is a little difficult currently to reconcile virtual-vs-physical behavior in the sim as there is only a single physical map and no virt-to-phys trans. we've just ignored this so far and said virtual=3D=3Dphysical. which is wh= y the sim throws an error when you try to put a virtual 0xffffffff80000000 address onto the physical bus. since 64-bit address aren't actually being used in the 32-bit env, why both= er using them ? seems like it'd be much easier to just use 32-bit addresses a= nd be done. -mike --Z7VyPvL0GdI/eL50 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWuuaqAAoJEEFjO5/oN/WBNTgP/3iF1fkMWuwGGCKAN/5V4+p0 rG4+TCxcoeJ3IjDTRKNZM8Nsk7nNOrvInsOyrRindY3b7H5DlG0diV8XxfilIcdn HZimXOOVKbA51O+H/KZIDYr9P1dboBWpgE/BgowMYv3LzOduYHO8+RF1ZrqrYE/N mcvE5xIkupURWCU2SSR0PBZ9YKomf79JJT2/u5gAf3JZq3wZjvJT0gC+hr6qACtr 0bvgicDWVIgx/X8rUXqeYlFxQGotbuBkN3bRlGYSKFqx3GPvkZ/iPnqOXiM8R6l2 UvQH+YUxMjEkRAHSC8z+9K47Bprb7eKMJN1sfmd3B3dcrPmMd9hAB+0mpd3gnB+M AyheCYe6dsr+XcSZ/6jelb5zn+8m8oIfaybVKo2Et/vNN5Ig8WwOHOQjUVSliY/j 5QKMPPHHD+TZ6+GMLGVbkqY8iu7DAJA/hOSF6RaFvc0TEN0t6HZVY2wz3HzBRTqU GFfVsF7hYarUvMk8lWkt575pczsZGoZCLPDL+2Ooe5B+P+Hg0yccrG5xK1uM+DOV pydG0BmgFCQtFpTZoiLcsgl3U2bLPl0cQLGb8N3STro655+EPWfmGMS0Df9oCw2a W43uQ7bTo8A3kU602qEWHrvHRr+OjudgQ1Df3O85zTyHVFqZp3vyV0tlxHMNkMz4 kXoACXtB4hB5YZDuDo+p =xxzN -----END PGP SIGNATURE----- --Z7VyPvL0GdI/eL50--