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 <[email protected]> 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, [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 >
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
