From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <13426df11003162137p2f927ea6qc8a279895d8f927a@mail.gmail.com> References: <13426df11003162137p2f927ea6qc8a279895d8f927a@mail.gmail.com> From: Noah Evans Date: Wed, 17 Mar 2010 10:15:57 +0100 Message-ID: <56a297001003170215v6de3c760n5b775713d9f048df@mail.gmail.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] recreational programming of an evening Topicbox-Message-UUID: eb7f6628-ead5-11e9-9d60-3106f5b1d025 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 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) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cat /proc/75/truss > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > > (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=3D 0x9 > 75 [cat] Pwrite 0x12ed 00000001 0fffdf30 00000009 00000009h=3D 0x9 > 75 [cat] Pread 0x13d7 00000000 0fffdf30 00002000 00002000h=3D 0xc > 75 [cat] Pwrite 0x12ed 00000001 0fffdf30 0000000c 0000000ch=3D 0xc > 75 [cat] Pread 0x13d7 00000000 0fffdf30 00002000 00002000h=3D 0 > 75 [cat] Open 0x1410 00006990 00000000 00000014 00000014h=3D 0x3 > 75 [cat] Pread 0x13d7 00000003 0fffff00 00000014 00000014h=3D 0xc > 75 [cat] Close 0x143e 00000003 0fffff00 00000014 00000014h=3D 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 >