This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: uprobes and empty functions
On Mon, 2010-11-01 at 10:42 -0700, Josh Stone wrote:
> On 11/01/2010 10:25 AM, Jim Keniston wrote:
> > On Sat, 2010-10-30 at 11:04 -0400, Frank Ch. Eigler wrote:
> >> I'm more worried that we're finding cases where uprobes is willing to
> >> place a breakpoint, but is not fully up to the job of executing the
> >> breakpointed instruction. To what extent could we flip over the tests
> >> from "known not to work" to "not known to work" in rejecting
> >> instructions?
> >
> > With x86, we always tended to err on the side of caution, declining to
> > probe instructions (and instruction prefixes) that we hadn't tested. At
> > some point, presumably, we decided we could handle rep prefixes, and I
> > know we tested probing ret instructions. For those of us not following
> > chip-bug workarounds, "rep ret" would seem like a very silly
> > instruction, and it's no surprise that we didn't test it.
>
> The problem is that we're validating the prefixes separately from the
> actual opcodes, without being sure that every combination works.
>
> I don't think we need to bother with asking what are "reasonable"
> prefixes on *every* opcode -- in truly illegal cases, the cpu will fault
> and uprobes should properly catch and clean up after. But on opcodes
> for which we have any kind of manual fixup or emulation, we need to be
> certain that we can handle prefixes as well, or else refuse to probe.
We do post-single-step fixups on almost all instructions -- typically
just redirecting the IP back to the probed instruction stream. ret is
one of the few instruction types where we figured we DON'T need to do a
fixup.
The difficulty in testing {k,u}probes's handling of every
prefix/instruction combo is that we have to verify that the probed
instruction did "the right thing" -- i.e., what the unprobed instruction
would do. Realistically, that means testing only instructions in
executables that produce predictable results. With kprobes, you at
least have a well-defined set of instructions that need to be tested --
i.e., all the instructions in the kernel and modules -- even if you
can't arrange to execute them all. With uprobes, the set of executables
we have to probe is unbounded.
>
> I'll try enhancing my patch to restrict this, and post it shortly...
>
> Josh
Jim