[Simh] VAX 780 & 3BSD

Kevin Handy kth at srv.net
Thu Feb 2 12:01:14 EST 2006


Rico Pajarola wrote:

>Hi all
>
>I just got 4.2BSD up and running thanks to Jason's detailed explanation! 
>Many thanks.
>
>Now I thought I'd try 3BSD... I started by replacing my 4.2BSD vmunix by 
>the vmunix in 3BSD, and that's what I get:
>VAX780 simulator V3.5-2
>
>Boot
>: ra(0,0)vmunix
>61856+61008+70120 start 0x4b4
>
>Segmentation fault (core dumped)
>
>simh crashed... I had a quick look with gdb, but the stack is wedged...
>
>Program received signal SIGSEGV, Segmentation fault.
>0x00000000 in ?? ()
>(gdb) bt
>#0  0x00000000 in ?? ()
>#1  0x00000000 in ?? ()
>#2  0x00000000 in ?? ()
>#3  0x00000002 in ?? ()
>#4  0x00000000 in ?? ()
>#5  0x0000001c in ?? ()
>#6  0x08097580 in xub ()
>...
>#11 0x00000000 in ?? ()
>#12 0x08095320 in ts_reg ()
>#13 0x00005354 in ?? ()
>...
>#174 0x00000000 in ?? ()
>#175 0x28094e72 in symlook_obj () from /libexec/ld-elf.so.1
>#176 0x0807c98a in do_cmd (flag=1,
>     fcptr=0x5 <Error reading address 0x5: Bad address>) at scp.c:784
>#177 0x0807de66 in main (argc=2, argv=0xbfbfeba0) at scp.c:614
>(gdb)
>
>The stack trace looks rather useless to me... Any obvious ideas / 
>starting points for debugging that?
>  
>

It looks like a possible problem using a library (from #175),
bad address (fcptr=0x5 which seems like a very low address,
meaning something earlier messed up the PC, and is calling
an error handler through the symlook_obj call),
and/or your stack is blown (memory corruption).

Start by turning off any optimizations when simh is compiled.
(Change -O2 to -O0 in makefile). This often helps get a better
stack trace (but not always)

You could play with the debug commands: like "set console
debug=stdout" and "set cpu debug".

Trace the emulation execution. There is no actual "trace"
command, so you have to use "step" commands. You could
try "step 1000" until it died, then do a binary search to get
within 100 of the actual failure, then single step through it
to find a place to set a breakpoint. After that, it is just
pounding away with the simh console and gdb until the
fault is found.




More information about the Simh mailing list