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

[Orlando Cazalet-Hyams via Phabricator via llvm-commits]

Orlando added a comment.

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

> In D111447#3060695 <https://reviews.llvm.org/D111447#3060695>, @Orlando wrote:
>
>> 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?
>
> It seems reasonable that we could add more specific scoring for these - right now in terms of points, the ranking of the following scenarios is:
> Both variables unavailable < One variable unavailable == Both variables available but different < Both variables available
>
> If we add the suggested "address name assigned but never checked" penalty, "One variable unavailable" would give a worse score than "Both variables available but different". Alternatively if we added an additional penalty for an address that was "successful" but didn't match elsewhere, then we would have  "Both variables available but different" would be worse. Which do you think would be best?

IMO "both variables available but different" should be treated as worse (higher penalty, lower desirability) than "one variable available". This fits the assumption that an incorrect value is more damaging to debugging experience than a missing one.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D111447/new/

https://reviews.llvm.org/D111447