[PATCH] D111447: [Dexter] Add DexDeclareAddress command and address function

Orlando Cazalet-Hyams via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Oct 13 02:12:56 PDT 2021


Orlando added a comment.

In D111447#3058958 <https://reviews.llvm.org/D111447#3058958>, @StephenTozer wrote:

> 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.

Cool, that SGTM.

>> 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.

That is a good point and I'm almost convinced. Again, from your test cross-project-tests/debuginfo-tests/dexter-tests/address.cpp: Am I right in thinking that if `a` is always reported as `optimized out` then the `DexExpectWatchValue` for `b` will always succeed? I wonder if "address name is assigned but never checked" and "address name is never assigned" should be cases for heuristic penalties. OTOH that adds complexity to and already complex command / interaction. What do you think?


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