[PATCH] D111447: [Dexter] Add DexDeclareAddress command and address function
Stephen Tozer via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Oct 12 09:40:27 PDT 2021
StephenTozer added a comment.
In D111447#3057619 <https://reviews.llvm.org/D111447#3057619>, @Orlando wrote:
> Am I right in thinking the main benefit is that `addr` is captured (on first use in a `DexExpectWatchValue`) which means we can use the value later, even if `a` has been `optimized out` when we want to check the value of `b`?
Yes - this doesn't necessarily just apply to optimized out variables but to any set of variables in the program, including variables in entirely disjoint scopes, or variables in the same scope at different points in time. This could also include comparing a variable to itself, such as `DexExpectValue('a', address('a'), address('a', 4), address('a', 8))` to test that an iterator increments correctly.
> I don't particularly like the way of assigning a value to the address variable: "In its first appearance it will match against any valid pointer". I'd prefer a dedicated command (or even rolling it into `DexDeclareAddress`) because this implicit behaviour is not very obvious when skimming a test. What do you think?
I considered a "declare a specific address once" version, but wasn't sure if it would be preferable, since it means that if the "canonical" address is not available at the point you declare it at then every test using the address would fail - even if every other use of the address is consistent. This is suitable for lit tests where we always expect sucess/failure to be binary, but it seems more brittle in score-based testing, which Dexter ostensibly supports. I'm not necessarily opposed to it, since it would simplify the code and the test syntax in some cases, but I'm not sure whether it's worth making the scoring heuristic less reliable.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D111447/new/
https://reviews.llvm.org/D111447
More information about the llvm-commits
mailing list