On Wed, 19 May 2010 17:32:19 PDT ron minnich wrote:
> On Wed, May 19, 2010 at 5:26 PM, Bakul Shah wro=
> te:
>
> > time ratrace -o /dev/null -c mk # about 19.67 seconds
>
> did you want [2]>/dev/null?
No, because that eats time output as well. My change uses a
new fd if -o is specified, 2 oth
I had a question from someone about the syscalltrace. It has not
relationship to the earlier devtrace work that Floren and I did.
Thanks
ron
On Wed, May 19, 2010 at 5:26 PM, Bakul Shah wrote:
> time ratrace -o /dev/null -c mk # about 19.67 seconds
did you want [2]>/dev/null?
> mk clean
> time mk # about 0.88 seconds
>
> And here I thought naming it ratrace would make it go faster.
Speed is left as an exercis
On Wed, 19 May 2010 15:25:52 PDT ron minnich wrote:
> On Wed, May 19, 2010 at 3:02 PM, Bakul Shah wrote
> :
>
> >> It gives you the option of not restarting the system call until later.
> >> There could be more complex usage scenarios.
> >
> > I don't understand this.
>
> You read the "start o
You THINK you have lots of control when you're dropping 'into' acid.
2010/5/19 ron minnich :
> On Wed, May 19, 2010 at 3:02 PM, Bakul Shah wrote:
>
>>> It gives you the option of not restarting the system call until later.
>>> There could be more complex usage scenarios.
>>
>> I don't understand this.
>
> You read the "start of the system call" message. The process
On Wed, May 19, 2010 at 2:48 PM, ron minnich wrote:
> 3. phooey. For some reason when a syscall fails the errstr prints an
> empty string. 9vx/trap.c: any suggestions?
Fixed.
Ron
On Wed, May 19, 2010 at 3:02 PM, Bakul Shah wrote:
>> It gives you the option of not restarting the system call until later.
>> There could be more complex usage scenarios.
>
> I don't understand this.
You read the "start of the system call" message. The process is
stopped. It has not run the sy
On Wed, 19 May 2010 13:38:36 PDT ron minnich wrote:
> On Wed, May 19, 2010 at 1:30 PM, Bakul Shah wro=
> te:
>
> > You write "startsyscall" to /syscall for every trace
> > buffer read -- don't quite understand why that is needed.
>
> It gives you the option of not restarting the system call un
1.name changed to ratrace
2. output now to stderr
3. phooey. For some reason when a syscall fails the errstr prints an
empty string. 9vx/trap.c: any suggestions?
ron
On Wed, May 19, 2010 at 1:30 PM, Bakul Shah wrote:
> You write "startsyscall" to /syscall for every trace
> buffer read -- don't quite understand why that is needed.
It gives you the option of not restarting the system call until later.
There could be more complex usage scenarios.
But it's a v
On Wed, 19 May 2010 11:33:24 PDT ron minnich wrote:
> On Wed, May 19, 2010 at 11:23 AM, Bakul Shah
> wrote:
>
> > Ok! I don't feel strongly either way. =A0But I hope you do
> > consider counted bytestrings to represent random memory.
> > It is cheap to parse and produce and doesn't lose info.
> strace on linux sends to stderr as well.
>
> OK, you win, I'll change that one. It bothers me to lose error output however.
if you really need bug-for-bug compatability,
you can always ratrace >[1=2] | ...
- erik
On Wed, May 19, 2010 at 11:43 AM, Bakul Shah wrote:
> BTW, truss does the same thing (output to stderr). ktrace on
> FreeBSD finesses by just dumping trace output to a file and
> then kdump is used to show it.
>
strace on linux sends to stderr as well.
OK, you win, I'll change that one. It bot
On Wed, May 19, 2010 at 2:23 PM, Bakul Shah wrote:
> On Wed, 19 May 2010 10:41:26 PDT ron minnich wrote:
>> On Wed, May 19, 2010 at 10:18 AM, Bakul Shah
>> wrote
>>
>> > 0. Name syscalltrace is too long :-)
>>
>> pick a name and I'll change it.
>
> I used strace but don't really care what you
On Wed, 19 May 2010 10:53:59 PDT ron minnich wrote:
> I'll only take that patch if it does NOT include stdio.h.
Well, you have the trivial diff so do what you want.
> As for output ... I'm conflicted on output on 1 vs. 2. But it is nice
> that you can see normal output of the traced process. Bu
On Wed, May 19, 2010 at 11:23 AM, Bakul Shah wrote:
> Ok! I don't feel strongly either way. But I hope you do
> consider counted bytestrings to represent random memory.
> It is cheap to parse and produce and doesn't lose info.
bear in mind that 99.999% of the time (well, that's an
exaggerat
> Ok! I don't feel strongly either way. But I hope you do
> consider counted bytestrings to represent random memory.
> It is cheap to parse and produce and doesn't lose info.
no keep it text. plan 9 wins this way. "bytestrings"
(it seems to me that byte strings are neither) would require
knowle
On Wed, 19 May 2010 10:41:26 PDT ron minnich wrote:
> On Wed, May 19, 2010 at 10:18 AM, Bakul Shah wrote
>
> > 0. Name syscalltrace is too long :-)
>
> pick a name and I'll change it.
I used strace but don't really care what you call it as long
as it is short! How about ratrace (Ron's ascii
On Wed, May 19, 2010 at 10:51 AM, erik quanstrom
wrote:
>> > if (cmd[0] != '/') {
>> > char* pcmd = malloc(strlen(cmd) + 5);
>> > sprintf(pcmd, "/bin/%s", cmd);
>> > exec(pcmd, args);
>> >
I'll only take that patch if it does NOT include stdio.h.
As for output ... I'm conflicted on output on 1 vs. 2. But it is nice
that you can see normal output of the traced process. But, hmm, if
traced process prints on 2, well ... you'll lose it.
So, my feeling is, if you are *really* concerned
> > if (cmd[0] != '/') {
> > char* pcmd = malloc(strlen(cmd) + 5);
> > sprintf(pcmd, "/bin/%s", cmd);
> > exec(pcmd, args);
> > }
shouldn't that be
On Wed, May 19, 2010 at 10:18 AM, Bakul Shah wrote:
> 0. Name syscalltrace is too long :-)
pick a name and I'll change it.
> 1. Curiously, an actual errstr is not enclosed in "..".
that goes on the bug list. If you want, use the bugtracker at
bitbucket.org, on my rminnich/vx32 project, and add
On Wed, 19 May 2010 08:09:50 PDT ron minnich wrote:
>
> The format arose out of discussions with nemo and others.
>
> It is a straight text layout of system call params and return. The =
> separates the params and return. The format is:
> pid textname syscall-name pc [params] = retval errstr
>
On Tue, May 18, 2010 at 10:45 PM, erik quanstrom wrote:
> ron, please enlighten the ignorant. could you constrast this with
> truss? or maybe there's a man page?
I need to write one.
The biggest diff from truss is that the program itself is dead simple,
since most of the work is done by the k
On Tue, May 18, 2010 at 10:40 PM, Bakul Shah wrote:
> term% 8.out -c /bin/echo Boo!
> 511 echo Brk 0x3233 b450 = 0 "" 0x11af077310cde470
> 0x11af077310d0da40
> 511 echo Pwrite 0x31d6 1 a458/"Boo!." 5 -0x1Boo!
> = 5 "" 0x11af07731e11e758 0x11af077326aed448
> 511 echo Op
On 19 May 2010, at 05:37, David Leimbach wrote:
On Tue, May 18, 2010 at 7:13 PM, ron minnich
wrote:
On Wed, May 19, 2010 at 1:54 AM, David Leimbach
wrote:
> Were all of the binaries within recompiled against this code?
Running 9vx
> on my iMac is pretty smooth!
Hm, not sure what
> term% 8.out -c /bin/echo Boo!
> 511 echo Brk 0x3233 b450 = 0 "" 0x11af077310cde470
> 0x11af077310d0da40
> 511 echo Pwrite 0x31d6 1 a458/"Boo!." 5 -0x1Boo!
> = 5 "" 0x11af07731e11e758 0x11af077326aed448
> 511 echo Open 0x32c0 9ec0/"#c/pid" = 3 "" 0x11af0773
On Tue, 18 May 2010 18:54:21 PDT David Leimbach wrote:
>
> Were all of the binaries within recompiled against this code? Running 9vx
> on my iMac is pretty smooth!
vx32/src/9vx.*.gz are the same as before (in case you are running those).
Compiling 9vx on a MAC OS 10.6.3 required changing HOST
On Tue, May 18, 2010 at 9:52 PM, ron minnich wrote:
> On Wed, May 19, 2010 at 4:37 AM, David Leimbach wrote:
>
> > There were pre-built binaries in this cloned repo, I'm totally unable to
> > rebuild the Mac OS X binary, due to some "impossible constraint" in some
> > assembly or something like
On Wed, May 19, 2010 at 4:37 AM, David Leimbach wrote:
> There were pre-built binaries in this cloned repo, I'm totally unable to
> rebuild the Mac OS X binary, due to some "impossible constraint" in some
> assembly or something like that per my recollection. I was merely wondering
> if you expe
On Tue, May 18, 2010 at 7:13 PM, ron minnich wrote:
> On Wed, May 19, 2010 at 1:54 AM, David Leimbach wrote:
>
> > Were all of the binaries within recompiled against this code? Running
> 9vx
> > on my iMac is pretty smooth!
>
> Hm, not sure what you mean.
>
> ron
>
> There were pre-built binari
On Wed, May 19, 2010 at 1:54 AM, David Leimbach wrote:
> Were all of the binaries within recompiled against this code? Running 9vx
> on my iMac is pretty smooth!
Hm, not sure what you mean.
ron
> Were all of the binaries within recompiled against this code? Running 9vx
> on my iMac is pretty smooth!
trace device doesn't require user land support.
- erik
On Tue, May 18, 2010 at 5:22 PM, ron minnich wrote:
> http://bitbucket.org/rminnich/vx32
>
> this is my hack of vx32.
>
Were all of the binaries within recompiled against this code? Running 9vx
on my iMac is pretty smooth!
Dave
>
> It includes a ram block device, but more importantly, it sup
http://bitbucket.org/rminnich/vx32
this is my hack of vx32.
It includes a ram block device, but more importantly, it supports the
system call trace code.
In the 'root' of the repo is the syscalltrace directory; cd in there
to make the syscalltrace binary.
Comments and improvements welcome. Noah
36 matches
Mail list logo
