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 Sat, 2010-10-30 at 11:04 -0400, Frank Ch. Eigler wrote:
> Josh Stone <jistone@redhat.com> writes:
> 
> > [...]
> > I wrote a uprobes patch, attached, which deals with "rep ret" by
> > treating it exactly like ret in the x86 uprobe_post_ssout (defined in
> > four places, sheesh...)
> 
> Great!
> 
> > I only matched "f3 c3", but I'm not sure if we need bother with other
> > rep/ret variants for this special case.  [...]
> 
> 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?
> 
> - FChE

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.

More exhaustive testing of the instruction set -- e.g., probing every
instruction in selected executables -- would be simplified by applying
the fix in PR #11376.  (I know, you're waiting for "test cases and doc
blurbs.")  Then there's the matter of somebody finding the time to do
the dejagnu incantations.

Jim 



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