[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