This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Roland McGrath wrote:I poked around the kernel source some more, but couldn't see what wasI figured you'd use some stap probes to follow the code paths!
going wrong.
Oh I did, but so much of it is inlined that it was incredibly difficult to follow.
I've changed the itrace code to stop the task after each step trap (so that it acts more like ptrace). I've tested this on several kernels (2.6.18-141.el5/ppc, 2.6.18-128.1.10.el5/x86_64/i686, and 2.6.25-14.fc9.ppc64) and it seems to work correctly.
Does anyone know who maintains ia64/utrace? David, was the above error on "old" utrace or "new"?
Does this seem like a reasonable work-around? Could there be problems with this approach?I presume it kills performance. But what works works, that's a what a work-around is. I'd hope that you don't make it use this "not really right" mode for kernels with the modern utrace interface that doesn't have this bug.
Yes, this is only for old utrace. As far as performance goes, I've benchmarked single-stepping '/bin/ls' on x86_64 with both approaches. Here's what I saw ('time' output, averages of 5 runs):
- no stopping on each step trap: real 0m3.735s user 0m0.328s sys 0m3.359s
- stopping on each step trap: real 0m4.101s user 0m0.336s sys 0m3.692s
I could also limit this work-around to ppc-only, to not penalize other architectures.
One last thing. I thought I'd try block stepping, so I got access to an ia64 machine. Unfortunately, using systemtap insn probes (either single or block step) lock up the system with a spinlock lockup. Sigh.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |