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: "stap -u" testing


Frank Ch. Eigler wrote:
Mike Mason <mmlnx@us.ibm.com> writes:

As far as I can tell, none of the tests invoke stap with the -u
option (unoptimized mode).  Doing so is revealing (see examples
below).  [...]

It would be worthwhile to review the history of the -u option in the archives. One will see that one of its motivations was specifically to minimize the effect of unpredictably incomplete debugging information for some $target variables. This way, only those variables actually used by end-user script code are asserted to exist, and tapsets can be optimistic in a sense.

I agree with optimizing away variables that aren't used in end user scripts. That's the right default behavior. I realize there will always be cases where we can't access certain $target variables. I still think the tests should expose those cases, then we can determine if something can be done about it. If we don't know there's a problem, we can't attempt to fix it.



It is true that this option can also mask cases where the named $target variables are completely wrong (that is, not present on any supportworthy kernel version). The difficulty lies in telling apart this class from the other one.

I don't think the tests need to differentiate between these two classes. Both are errors, though one may be fixable and the other not. Leave it up to the person analyzing the results to make that call.


Mike


- FChE


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