<div dir="ltr"><div>I'll admit that this is a little over my head, but the code was easy enough to add:<br><br>PTE not SYS abort, ptead = 7fffe4, ptidx = FFFFE4, d_p0br = 8034DC00, d_p1br = FF800000<br><br></div>-Henry<br><div><div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 17 February 2016 at 17:31, Bob Supnik <span dir="ltr"><<a href="mailto:bob@supnik.org" target="_blank">bob@supnik.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The code path to get to this problem is quite short:<br>
<br>
TLBENT fill (uint32 va, int32 lnt, int32 acc, int32 *stat)<br>
{<br>
int32 ptidx = (((uint32) va) >> 7) & ~03;<br>
int32 tlbpte, ptead, pte, tbi, vpn;<br>
static TLBENT zero_pte = { 0, 0 };<br>
<br>
if (va & VA_S0) { /* system space? */<br>
    if (ptidx >= d_slr) /* system */<br>
        MM_ERR (PR_LNV);<br>
    ptead = (d_sbr + ptidx) & PAMASK;<br>
    }<br>
else {<br>
    if (va & VA_P1) { /* P1? */<br>
        if (ptidx < d_p1lr)<br>
            MM_ERR (PR_LNV);<br>
        ptead = d_p1br + ptidx;<br>
        }<br>
    else {                                              /* P0 */<br>
        if (ptidx >= d_p0lr)<br>
            MM_ERR (PR_LNV);<br>
        ptead = d_p0br + ptidx;<br>
        }<br>
    if ((ptead & VA_S0) == 0)<br>
        ABORT (STOP_PPTE);                              /* ppte must be sys */<br>
<br>
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.<br>
<br>
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.<br>
<br>
    if ((ptead & VA_S0) == 0){<br>
        printf ("PTE not SYS abort, ptead = %x, ptidx = %X, d_p0br = %X, d_p1br = %X\r\n", ptead, ptidx, d_p0br, d_p1br);<br>
        ABORT (STOP_PPTE);                              /* ppte must be sys */<br>
        }<br>
<br>
The cr-lf is needed because the console is still in raw mode at that point.<br>
<br>
/Bob<br>
<br>
On 2/17/2016 3:22 PM, <a href="mailto:simh-request@trailing-edge.com" target="_blank">simh-request@trailing-edge.com</a> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Message: 3<br>
Date: Wed, 17 Feb 2016 15:14:04 -0500<br>
From: Paul Koning<<a href="mailto:paulkoning@comcast.net" target="_blank">paulkoning@comcast.net</a>><br>
To: Howard Bussey<<a href="mailto:howard.bussey@gmail.com" target="_blank">howard.bussey@gmail.com</a>><br>
Cc: simh mailing list<<a href="mailto:simh@trailing-edge.com" target="_blank">simh@trailing-edge.com</a>><span><br>
Subject: Re: [Simh] Recent build crashes on OSX<br></span>
Message-ID:<<a href="mailto:2884B212-B6D6-4C86-81C4-937FDDDBDE33@comcast.net" target="_blank">2884B212-B6D6-4C86-81C4-937FDDDBDE33@comcast.net</a>><br>
Content-Type: text/plain; charset=utf-8<span><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>On Feb 17, 2016, at 3:01 PM, Howard Bussey<<a href="mailto:howard.bussey@gmail.com" target="_blank">howard.bussey@gmail.com</a>>  wrote:<br>
><br>
>Googling “Process PTE …” shows this occurred before:<br>
><br>
><a href="http://mailman.trailing-edge.com/pipermail/simh/2010-May/010760.html" rel="noreferrer" target="_blank">http://mailman.trailing-edge.com/pipermail/simh/2010-May/010760.html</a><br>
><br>
>The suggestion was to try turning off optimization when compiling simh…<br>
</blockquote>
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.<br>
<br>
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).<br>
<br>
More info can be found here:<a href="https://homes.cs.washington.edu/~akcheung/papers/apsys12.pdf" rel="noreferrer" target="_blank">https://homes.cs.washington.edu/~akcheung/papers/apsys12.pdf</a>  -- a very good article that all C programmers should read.<br>
<br>
</span></blockquote><div><div>
<br>
_______________________________________________<br>
Simh mailing list<br>
<a href="mailto:Simh@trailing-edge.com" target="_blank">Simh@trailing-edge.com</a><br>
<a href="http://mailman.trailing-edge.com/mailman/listinfo/simh" rel="noreferrer" target="_blank">http://mailman.trailing-edge.com/mailman/listinfo/simh</a></div></div></blockquote></div><br></div></div></div></div></div></div></div>