From patchwork Thu Mar 10 14:08:51 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Matthew Fortune X-Patchwork-Id: 11299 Received: (qmail 110762 invoked by alias); 10 Mar 2016 14:09:03 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 110673 invoked by uid 89); 10 Mar 2016 14:09:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL, BAYES_00, MIME_BASE64_BLANKS, RCVD_IN_DNSWL_NONE, RP_MATCHES_RCVD, SPF_PASS autolearn=ham version=3.3.2 spammy=bear, sk:address, boil, addr X-HELO: mailapp01.imgtec.com Received: from mailapp01.imgtec.com (HELO mailapp01.imgtec.com) (195.59.15.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 10 Mar 2016 14:08:55 +0000 Received: from HHMAIL01.hh.imgtec.org (unknown [10.100.10.19]) by Websense Email Security Gateway with ESMTPS id A80A61689F022; Thu, 10 Mar 2016 14:08:50 +0000 (GMT) Received: from hhmail02.hh.imgtec.org ([fe80::5400:d33e:81a4:f775]) by HHMAIL01.hh.imgtec.org ([fe80::710b:f219:72bc:e0b3%26]) with mapi id 14.03.0266.001; Thu, 10 Mar 2016 14:08:52 +0000 From: Matthew Fortune To: Mike Frysinger , Maciej Rozycki CC: Steve Ellcey , "gdb-patches@sourceware.org" Subject: RE: MIPS simulator is broken Date: Thu, 10 Mar 2016 14:08:51 +0000 Message-ID: <6D39441BF12EF246A7ABCE6654B023536BBB22F1@hhmail02.hh.imgtec.org> References: <5f31ca78-325c-4c18-9abf-16de50bac964@BAMAIL02.ba.imgtec.org> <20160112010025.GE4894@vapier.lan> <20160210072842.GX7732@vapier.lan> In-Reply-To: <20160210072842.GX7732@vapier.lan> MIME-Version: 1.0 Mike Frysinger writes: > since 64-bit address aren't actually being used in the 32-bit env, why > bother using them ? seems like it'd be much easier to just use 32-bit > addresses and be done. Hi Mike, The problem here is fairly common and seems to boil down to a misunderstanding at some level of the MIPS trick for 32-bit running on 64-bit architectures. I agree that the address translation logic for MIPS seems weird but I also don’t think it should not get changed just because it looks odd without understanding why it is that way. As such for the time being I propose reverting both changes to MIPS sim to get it working again: Revert "sim: mips: delete mmu stubs to move to common sim_{read,write}" This reverts commit 26f8bf63bf36f9062a5cc1afacf71462a4abe0c8. Revert "sim: mips: workaround 32-bit addr sign extensions" This reverts commit b36d953bced0a4fecdde1823abac70ed7038ee95. I'd assume this is OK given it 'fixes' the regression despite taking the code back to its unusual, but working, state. I don't fully understand GNUSIM internals so please bear with me while I get up to speed... Let's assume we just delete the masking of address in address_translation: Where we could aim for is that when simulating a 64-bit architecture then all addresses (including those coming from o32 or n32 applications) should be seen as 64-bit and sign extended (NOT zero extended) from the 32-bit values seen in the ELF. This means code in an o32 ELF with address 0x80010000 should be loaded at 0xffffffff80010000 and executed from that 64-bit address. When presenting addresses to the user the upper 32-bits can be discarded as they are irrelevant but internally in the sim they could be represented. It seems this is how things work and I see sections being loaded at sign extended 64-bit addresses addresses but even when I claim to have a memory region at that 64-bit address I still get the read to unmapped address error as the code does not appear to get loaded: run --memory-region 0xffffffff80010000,0x10000 sanity.s.x Loading section .text, size 0x60 lma 0xffffffff80010000 Loading section .MIPS.abiflags, size 0x18 lma 0x400098 Loading section .data, size 0x1a lma 0xffffffff80010060 mips-core: 4 byte read to unmapped address 0xffffffff80020000 at 0xffffffff80020000 program stopped with signal 10 (User defined signal 1). The trace output shows this: insn: 0x80010000 --- _start nop - SLLb insn: 0x80010004 --- _start nop - SLLb insn: 0x80010008 --- _fail nop - SLLb insn: 0x8001000c --- _fail nop - SLLb insn: 0x80010010 --- _fail nop - SLLb insn: 0x80010014 --- _fail nop - SLLb Can you help me understand why the code does not get loaded and/or if there is somewhere else we may need to educate about sign extended addresses? Thanks, Matthew diff --git a/sim/mips/sim-main.c b/sim/mips/sim-main.c index 916769e..8cf5743 100644 --- a/sim/mips/sim-main.c +++ b/sim/mips/sim-main.c @@ -68,7 +68,7 @@ address_translation (SIM_DESC sd, /* For a simple (flat) memory model, we simply pass virtual addressess through (mostly) unchanged. */ - vAddr &= 0xFFFFFFFF; +// vAddr &= 0xFFFFFFFF; *pAddr = vAddr; /* default for isTARGET */ *CCA = Uncached; /* not used for isHOST */