RE: MIPS simulator is broken

[Matthew Fortune <Matthew dot Fortune at imgtec dot com>]

Ping.

Matthew Fortune <matthew.fortune@imgtec.com> writes:
> Mike Frysinger <vapier@gentoo.org> 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:
> 
> 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 */
> 
> 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