UIDF dialog doesn't always populate with existing value

[negasora]

Repro steps:

1. Open the attached bndb
2. Right click > set user variable value on rsi in the printf call at any IL level >= MLIL
3. Notice the dialog displays UndeterminedValue instead of the set UIDF value

uidf_dialog_bug.zip

[psifertex]

This is a recent regression caused by the introduction of the ASSERT() syntax. If you select the variable in the ASSERT itself, the default value will be shown.

[psifertex]

I found a few other related issues I'm going to track here and I'm going to bump the impact because they make UIDF WAY more painful then they should be.

• Once you've set UIDF, there's no way to remove it. In particular, the dialog itself won't accept "Undetermined Value" unless you do some shenanigans like enter a constant, select the constanttype from the list, then go BACK to undetermined and then remove the value itself. Otherwise the "Accept" button is literally locked. However, even if you do...
• Re-setting a variable UIDF to UndeterminedValue after it's been set is apparently treated as a NOP or at least doesn't appear to do anything
• Related, we should have an action/menu item to remove existing ASSERTS/UIDF.

[psifertex]

Moving to impact high as unfortunately there are no work-arounds and once you've set a UIDF value you're basically stuck afaict.

[psifertex]

Actually, bumping this down to medium. I can't re-create the failure to reset. I think the work-around is that you have to make sure to reset the variable in the ASSERT( instead of at the previous point. Given that I don't think this is as critical anymore and we can probably resolve with some smaller fixes.

[spoonmilk]

The issue here seems to stem from the printf and assert being at different addresses, so we have to check if the variable is dominated by an assert which had previously set the value and get that value from it. Working toward a fix.

In the process, I've also found many more bugs with the UIDF setting in general that I'll file separate issues for. Some are the ones Jordan mentioned above, and there's another with setting a value in rsi early in the function, where the ASSERT() appears on argv (which is technically the right variable since it corresponds to rsi, but wrong location)

[rssor]

I would actually just scope this down to: populate with correct UIDF when opening the dialog on the right address for now, we can make it populate at dominated-by locations later on. the issue where it was setting rsi value 'before' despite right clicking on rsi in dest position on an instruction is probably the highest priority bug to fix