MIPS simulator is broken
Matthew Fortune
Matthew.Fortune@imgtec.com
Thu Mar 10 14:09:00 GMT 2016
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
More information about the Gdb-patches
mailing list