From mboxrd@z Thu Jan 1 00:00:00 1970 From: newsham@lava.net (Tim Newsham) Date: Sun, 4 May 2008 20:59:25 -1000 (HST) Subject: [Unix-jun72] C compiler status In-Reply-To: <20080505060824.GA78841@minnie.tuhs.org> References: <20080505060824.GA78841@minnie.tuhs.org> Message-ID: > 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/