From: wkt@tuhs.org (Warren Toomey)
Subject: [Unix-jun72] C compiler status
Date: Mon, 5 May 2008 17:12:12 +1000 [thread overview]
Message-ID: <20080505071212.GA80277@minnie.tuhs.org> (raw)
In-Reply-To: <Pine.BSI.4.64.0805042053350.20114@malasada.lava.net>
On Sun, May 04, 2008 at 08:59:25PM -1000, Tim Newsham wrote:
> 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.
Thanks Tim.
It looks like we are not starting /usr/lib/c0 properly: the CPU never gets
to execute at 040000, and we end up in sysbreak without ever calling it.
I have a CPU history from sysexec at 004250 right up to where it hits a
supposed HALT instruction in sysbreak at 005752, which previously was
CMP R1,SP.
Here's the simh and Unix commands I tried:
./simh.cfg
sim> c
:login: root
# /tmp/a.out # Mount /usr
# chdir /usr/tmp
#
Simulation stopped, PC: 007332 (MOV (SP)+,25310)
sim> break 004250
sim> c
/usr/lib/c0 z.c a b # Run pass c0 on z.c, creating a & b tempfiles
Breakpoint, PC: 004250 (JSR R0,5634)
sim> set CPU HISTORY=0
sim> set CPU HISTORY=100000
sim> continue
HALT instruction, PC: 005754 (BCC 5762)
sim> show CPU HISTORY
I won't include the history here, as it's 49,000 instructions. But if
anybody wants a look at it, let me know.
Thanks,
Warren
>
> 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/
> _______________________________________________
> Unix-jun72 mailing list
> Unix-jun72 at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/unix-jun72
next prev parent reply other threads:[~2008-05-05 7:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-05 6:08 Warren Toomey
2008-05-05 6:59 ` Tim Newsham
2008-05-05 7:12 ` Warren Toomey [this message]
2008-05-05 7:50 ` Warren Toomey
2008-05-05 8:02 ` [Unix-jun72] C compiler: it works! Warren Toomey
2008-05-05 8:38 ` Warren Toomey
2008-05-05 16:57 ` [Unix-jun72] C compiler status Tim Newsham
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080505071212.GA80277@minnie.tuhs.org \
--to=wkt@tuhs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).