On Wed, 19 May 2010 13:38:36 PDT ron minnich <[email protected]> wrote:
> On Wed, May 19, 2010 at 1:30 PM, Bakul Shah <[email protected]> wro=
> te:
>
> > You write "startsyscall" to <pid>/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.
I don't understand this.
> But it's a very good point. We've talked about dumping this data via
> the trace facility instead. Trace facility is well designed for this
> type of output -- I've got a proposal in which Sape says is ok for
> changing the format of the trace records.
You will go over to the dark side of binary formats? Horrors!
> So, things can still change. One question though -- once you get to
> the point of really complex examination of system calls, would acid be
> better? Or do you see a use for ratrace (that name is kind of funny
> and has the virtue of being typable on my keyboard with one hand) just
> to dump more data and make all data visible? Your point about lost
> information is a good one.
There is value in being able to trace syscalls outside of a
debugger. For instance I have done things like
strace -f make -j14 |& grep 'open("'
ktrace -di make -j14 && kdump | grep 'open("'
to look at parallel build problems due to messed up
dependencies. I have used tracing to find all the annoying
hidden config files, dlopened shared libs, pam (pluggable
authentication module) and what not that programs seem to use
these days.
I like the simplicity of cat <pid>/syscall!
