[Simh] Recent build crashes on OSX

Bob Supnik bob at supnik.org
Wed Feb 17 17:31:50 EST 2016


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, simh-request at trailing-edge.com wrote:
> Message: 3
> Date: Wed, 17 Feb 2016 15:14:04 -0500
> From: Paul Koning<paulkoning at comcast.net>
> To: Howard Bussey<howard.bussey at gmail.com>
> Cc: simh mailing list<simh at trailing-edge.com>
> Subject: Re: [Simh] Recent build crashes on OSX
> Message-ID:<2884B212-B6D6-4C86-81C4-937FDDDBDE33 at comcast.net>
> Content-Type: text/plain; charset=utf-8
>
>
>> >On Feb 17, 2016, at 3:01 PM, Howard Bussey<howard.bussey at gmail.com>  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.
>



More information about the Simh mailing list