[Simh] Recent build crashes on OSX

[Henry Bent]

I'll admit that this is a little over my head, but the code was easy enough
to add:

PTE not SYS abort, ptead = 7fffe4, ptidx = FFFFE4, d_p0br = 8034DC00,
d_p1br = FF800000

-Henry

On 17 February 2016 at 17:31, Bob Supnik <bob at supnik.org> wrote:

> 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.
>>
>>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20160218/80477946/attachment-0001.html>