It could be that this sort of memory operation is what
is causing the
problem. Is there a way for simh to give an instruction trace beginning
at a certain address e.g. 040000, so I can watch c0's behaviour and see
where it goes off the rails?
Simh has a cpu execution history which is already turned on in our
configuration file, so at any point when youre at the simh prompt
you can "show cpu history" to see the recently executed instructions.
You can also use breakpoints to do some tracing, for example:
break 1350;ex r0;go
will break at 1350, in syscall right after it figures out what syscall
number, dump r0, which has the syscall number, and continue, so that
you get a running syscall trace..
The downside to these methods is that they capture the entire operating
system, not just a single userland process... It would be nice if
we could rig the emulator to skip over context switches to other
processes.... Then again, it's probably a lot easier than debugging
with blinking lights and switches...
Warren
I suspect there are some more kernel gotchas left to be found. The
fact that "cc" doesnt work properly could be due to my 0407 patch
but could equally be another kernel typo somewhere. The fact that
init doesnt like running getty on other ttys is also making me suspect
some hidden kernel bugs... During one of my tests with "cc" I saw
it go into panic (probably good to run with a breakpoint on panic,
too! see build/a.out.syms) after syscall got reentered!
Tim Newsham
http://www.thenewsh.com/~newsham/