9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Noah Evans <noah.evans@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] recreational programming of an evening
Date: Wed, 17 Mar 2010 10:15:57 +0100	[thread overview]
Message-ID: <56a297001003170215v6de3c760n5b775713d9f048df@mail.gmail.com> (raw)
In-Reply-To: <13426df11003162137p2f927ea6qc8a279895d8f927a@mail.gmail.com>

Doing shell debugging I wrote a fork tracer that would setproc() the
return value of every fork call if non-zero. That worked fine if only
the parent did the forking but it was a pain if different processes
forked at different times it was even more useless when the forked
process immediately exec'ed because acid assumes all of the processes
it is debugging have the same symbols and address space.

Anybody with more experience than me with this kind of debugging have
any experience they'd like to share?

Noah

On Wed, Mar 17, 2010 at 5:37 AM, ron minnich <rminnich@gmail.com> wrote:
> I'm an admirer of acid but never found that I like the truss functions
> all that much. I've used acid on just enough semi-working platforms,
> where breakpoints don't do what is expected, that truss is not
> frequently operational and hence not that useful. Also, it's not that
> great for fork. And, I'm not that happy about the need to change the
> process' memory image just to do tracing. truss() just feels
> unfinished.
>
> I pretty much prefer strace on Unix to what acid can do on Plan 9. It
> follows forks nicely, and it shows what's going on. And, it works even
> if debugging doesn't. And, and on a lightweight node, I don't have to
> drag all the acid bits along.
>
> Now, on Linux, strace is a beast: 256KB binary, needs shared
> libraries, and so on. (come to think of it that's small for a GNU
> program nowadays ...)
>
> What I want is something that works like this:
> echo stop > proc/75/ctl
> while (echo startsyscall>/proc/75/ctl) {
>                cat /proc/75/truss
>                }
>
> (note the undocumented startsyscall verb). You need to see the source,
> not the man page :-)
>
> Well, turns out to be trivial to do in Plan 9. I did the work against
> 9vx, since it's so easy to prototype this stuff. The diff is so small
> I just attached it. Russ already had nice pretty-print examples for
> tracing system calls so I cribbed them.
>
> Here's the output:
>
> 75 [cat] Pread 0x13d7 00000000 0fffdf30 00002000 00002000h= 0x9
> 75 [cat] Pwrite 0x12ed 00000001 0fffdf30 00000009 00000009h= 0x9
> 75 [cat] Pread 0x13d7 00000000 0fffdf30 00002000 00002000h= 0xc
> 75 [cat] Pwrite 0x12ed 00000001 0fffdf30 0000000c 0000000ch= 0xc
> 75 [cat] Pread 0x13d7 00000000 0fffdf30 00002000 00002000h= 0
> 75 [cat] Open 0x1410 00006990 00000000 00000014 00000014h= 0x3
> 75 [cat] Pread 0x13d7 00000003 0fffff00 00000014 00000014h= 0xc
> 75 [cat] Close 0x143e 00000003 0fffff00 00000014 00000014h= 0
> 75 [cat] Exits 0x128b 00000000 00000000 00000000 00000000hecho: write
> error: process exited
>
> So, voila, we have truss, it took 15 minutes to add this in, in fact
> almost as long to write this message as to add it in. And a day to
> look at the code and ruminate in the odd free moment how to do it. But
> that's why I still like this kernel: I can image how much fun this
> would have been in just about any Unix, since I've been through a
> similar exercise of this sort frequently on Linux.
>
> I may extend it just a bit to dump stuff like file names, read and
> write data, and so on. Not that hard in my view.
>
> Anyway, I'll be doing the same thing in the 9k kernel, but the patch I
> just attached should give you a hint if you need this. I think it
> would help people trying to find problems in 9vx. And, I bet somebody
> out there can do a better job than I did.
>
> Obviously, you need to do a bit more work to catch fork but that's
> left to the student.
>
> ron
>



  reply	other threads:[~2010-03-17  9:15 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-17  4:37 ron minnich
2010-03-17  9:15 ` Noah Evans [this message]
2010-03-17 15:12   ` ron minnich
2010-03-21  5:48 ron minnich
2010-03-21  8:30 ` EBo
2010-03-21 17:36 ` Stuart Morrow
2010-03-21 17:39   ` erik quanstrom
2010-03-21 21:47   ` ron minnich
2010-03-21 22:02     ` EBo
2010-03-21 22:56       ` hiro
2010-03-22  0:02         ` EBo
2010-03-22 15:50           ` David Leimbach
2010-03-22 15:57             ` andrey mirtchovski
2010-03-22 16:09               ` David Leimbach
2010-03-22 17:22                 ` Chad Brown
2010-03-22 17:54                   ` Chad Brown
2010-03-22 16:09               ` erik quanstrom
2010-03-21 23:19       ` Ethan Grammatikidis
2010-03-21 23:54         ` EBo
2010-03-22  5:57         ` Skip Tavakkolian
2010-03-22 15:47     ` David Leimbach
2010-03-22 16:07       ` ron minnich
2010-03-21 17:57 ` Bakul Shah
2010-03-21 18:03   ` Devon H. O'Dell
2010-03-21 18:59     ` Lyndon Nerenberg
2010-03-21 22:08       ` EBo
2010-03-21 19:37     ` Steve Simon
2010-03-21 20:41     ` Bakul Shah
2010-03-21 21:48   ` ron minnich

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=56a297001003170215v6de3c760n5b775713d9f048df@mail.gmail.com \
    --to=noah.evans@gmail.com \
    --cc=9fans@9fans.net \
    /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).