This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
RE: MIPS simulator is broken
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: 'Mike Frysinger' <vapier at gentoo dot org>, Maciej Rozycki <Maciej dot Rozycki at imgtec dot com>
- Cc: "'gdb-patches at sourceware dot org'" <gdb-patches at sourceware dot org>
- Date: Tue, 5 Apr 2016 08:33:21 +0000
- Subject: RE: MIPS simulator is broken
- Authentication-results: sourceware.org; auth=none
- References: <5f31ca78-325c-4c18-9abf-16de50bac964 at BAMAIL02 dot ba dot imgtec dot org> <20160112010025 dot GE4894 at vapier dot lan> <alpine dot DEB dot 2 dot 00 dot 1601301501580 dot 5958 at tp dot orcam dot me dot uk> <20160210072842 dot GX7732 at vapier dot lan> <6D39441BF12EF246A7ABCE6654B023537E3A3580 at HHMAIL01 dot hh dot imgtec dot org>
Ping^2
> 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