[Simh] Tracing in SimH

[Bob Supnik]

One way to do this is to place a SimH breakpoint at the indicated virtual address, and turn on the history function:

sim> set break 8002E093
sim> set cpu history=<number of instructions, less than 65K>

When execution reaches the breakpoint, the last <number of instructions> will be in the history buffer and can be dumped to a file with the SHOW CPU HISTORY command. You can increase the length of the history buffer, if needed, by modifying the source and recompiling.

However... "Process PTE in P0 or P1 space" is an internal diagnostic that indicates corruption in the process page tables or the base registers.  The relevant code from VAX_MMU.c is:

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 */

It will be impossible to tell, from the history buffer, which of the memory references involved caused the problem.

The best way of tackling this problem, at least to start, is to use host operating system debugging.  Put a host breakpoint on the line of code marked with **. Dump out the variables, in particular, ptidx, ptead, va, d_p0br, d_p1br.  va should tell you which memory reference is involved.  Then, you can reconstruct the actual chain of address calculations and see whether d_p0br or d_p1br is possibly corrupt.  Once you know whether the problem lies in P0 or P1 space, you can use the history buffer to see where the last write occurred to P0BR or P1BR.

Alternately, you can refactor the code as follows:

else {
    if (va & VA_P1) {                                   /* P1? */
        if (ptidx < d_p1lr)
            MM_ERR (PR_LNV);
        ptead = d_p1br + ptidx;
        if ((ptead & VA_S0) == 0)
**          ABORT (STOP_PPTE);                          /* ppte must be sys */
        }
    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 */
        }

Then, which breakpoint gets hit will tell you whether it was a P0 or P1 reference that is causing the problem, and thus whether P0BR or P1BR is the culprit.

/Bob Supnik

----- Original Message -----
From: simh-request at trailing-edge.com
To: simh at trailing-edge.com
Sent: Friday, January 8, 2010 12:00:01 PM GMT -05:00 US/Canada Eastern
Subject: Simh Digest, Vol 74, Issue 4

Send Simh mailing list submissions to
	simh at trailing-edge.com

To subscribe or unsubscribe via the World Wide Web, visit
	http://mailman.trailing-edge.com/mailman/listinfo/simh
or, via email, send a message with subject or body 'help' to
	simh-request at trailing-edge.com

You can reach the person managing the list at
	simh-owner at trailing-edge.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Simh digest..."


Today's Topics:

   1.  weird problem with SIMH on Linux.. (maybe other UNIX??)
      (Jason Stevens)


----------------------------------------------------------------------

Message: 1
Date: Thu, 7 Jan 2010 13:47:12 -0500
From: Jason Stevens <neozeed at gmail.com>
Subject: [Simh] weird problem with SIMH on Linux.. (maybe other
	UNIX??)
To: simh at trailing-edge.com
Message-ID:
	<46b366131001071047h15710ffbp1a8e3a831b61182a at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

I was going to start putting together some builds for Linux/Net/Open/FreeBSD
when I noticed that booting 4.3 BSD will not work on these platforms...

While it does run on windows.

On Linux (the x86 platform, Debian..) I get the following when trying to run
4.3 BSD Uwisc


Boot
: hp(0,0)vmunix
29104+89584+102928 start 0x12f8

Process PTE in P0 or P1 space, PC: 8002E093 (XORW3
@-7035(R8), at DOFF8C9A, at -70B0(R1))
sim> quit
Goodbye
#

Is there an automated way to have SIMH single step through something and
dump the cpu state as it goes along?  I suspect there is some weird bug in
the VAX 11/780 that manifests itself when booting on Linux...

I know I had this issue with the iphone running OSX on an ARM CPU, but I
shrugged it off to the platform/compiler as it was all 'hacked' however now
I'm wondering if it's something weirdly unixy related....

my disk images & ini are easier to download from here if anyone else cares
to test a unix version of SIMH..
http://sourceforge.net/projects/bsd42/files/4BSD%20under%20Windows/v0.4/4.3BSD-Uwisc-install-0.4.exe/download

Thanks for your time!

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.trailing-edge.com/pipermail/simh/attachments/20100107/35ca738a/attachment-0001.html 

------------------------------

_______________________________________________
Simh mailing list
Simh at trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

End of Simh Digest, Vol 74, Issue 4
***********************************