The code path to get to this problem is quite short:
TLBENT fill (uint32 va, int32 lnt, int32 acc, int32 *stat)
{
int32 ptidx = (((uint32) va) >> 7) & ~03;
int32 tlbpte, ptead, pte, tbi, vpn;
static TLBENT zero_pte = { 0, 0 };
if (va & VA_S0) { /* system space? */
if (ptidx >= d_slr) /* system */
MM_ERR (PR_LNV);
ptead = (d_sbr + ptidx) & PAMASK;
}
else {
if (va & VA_P1) { /* P1? */
if (ptidx < d_p1lr)
MM_ERR (PR_LNV);
ptead = d_p1br + ptidx;
}
else { /* P0 */
if (ptidx >= d_p0lr)
MM_ERR (PR_LNV);
ptead = d_p0br + ptidx;
}
if ((ptead & VA_S0) == 0)
ABORT (STOP_PPTE); /* ppte must be
sys */
ANSI C (and old C) both define right shifts on unsigned integers as
doing zero fills from the left. Therefore, ptidx must have seven leading
0's and, by the mask operation, 2 trailing 0's. Note that ptidx passes
the length checks, or the abort wouldn't be reached.
At the stop, the console is still active, and it should be possible to
dump P0BR and P1BR. Note that the internal form (d_p0br and d_p1br) has
been modified from the visible form. So put a breakpoint on the ABORT or
a print statement beforehand (the joys of open sauce) to check that the
internal values are all right.
if ((ptead & VA_S0) == 0){
printf ("PTE not SYS abort, ptead = %x, ptidx = %X, d_p0br =
%X, d_p1br = %X\r\n", ptead, ptidx, d_p0br, d_p1br);
ABORT (STOP_PPTE); /* ppte must be
sys */
}
The cr-lf is needed because the console is still in raw mode at that point.
/Bob
On 2/17/2016 3:22 PM, [email protected] wrote:
Message: 3
Date: Wed, 17 Feb 2016 15:14:04 -0500
From: Paul Koning<[email protected]>
To: Howard Bussey<[email protected]>
Cc: simh mailing list<[email protected]>
Subject: Re: [Simh] Recent build crashes on OSX
Message-ID:<[email protected]>
Content-Type: text/plain; charset=utf-8
>On Feb 17, 2016, at 3:01 PM, Howard Bussey<[email protected]> wrote:
>
>Googling “Process PTE …” shows this occurred before:
>
>http://mailman.trailing-edge.com/pipermail/simh/2010-May/010760.html
>
>The suggestion was to try turning off optimization when compiling simh…
In that case, gcc is the compiler. In the case Michael mentioned, it's LLVM.
So the conclusion is that it's a SimH bug, non-compliant code that gets caught
by modern optimizing compilers.
Turning on GCC warnings may help; a lot of issues of this kind are reported as warnings
if you build with -Wall. I don't see anything interesting when I try that on OSX, but
that's LLVM. When I try it on Linux, I get a bunch of possible uninitialized variables
-- those are sometimes false warnings but worth looking at. More interesting is a bunch
of "does break strict-aliasing rules". Those indicate incorrect (not ANSI
compliant) code that you used to be able to get away with, but can't any longer when
optimization is enabled. The correct way to handle those errors is to fix the code, not
to disable the warning or the optimization (as is done by some other software teams).
More info can be found
here:https://homes.cs.washington.edu/~akcheung/papers/apsys12.pdf -- a very
good article that all C programmers should read.
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
