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]

Re: uprobes and empty functions


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.

I'll try enhancing my patch to restrict this, and post it shortly...

Josh


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]