register type inferrence bug

[kuk0]

context: in the logging module, you need some free registers so you shift them and call update_reg_usage; the problem is that some registers may cross the 16reg boundary a you need to add further instructions to move them from high to low - this is what the expand_opr in modify.ml is supposed to do...
to move a register, you need to know, whether it's a normal register (say int; and move instr. should be used) or an object reference (and move-obj should be used)

you try to infer the register type by doing a data flow analysis, but then consider just the first type!

i encountered code where this approach failed: a register was an object reference, but it was first initialized as 0 (NULL) which made redexer think it is an int...
(0 seems to be the only ambiguous value)

[jsjeon]

I guess calling List.hd right after get_sort made you think that it only uses the first type, but that's just for taming OCaml's strong type system. Note that the type of get_sort is instr -> int list -> reg_sort list, and that it is used at lines 1277, 1319, and 1382. Except for the last case, where the function inputs [d; s] and outputs [op_d; op_s], the function is used with a list of a single register number. Hence, calling List.hd so as to retrieve one and only reg_sort. This commit log may help you understand how they looked like: ad82bf9

[jsjeon]

Regarding a register for object reference which is first initialized as null, I don't have a clear solution at this moment... When using dexdump, we can see local variables associated with names and types, so I wonder either annotations or debug info hold much more precise informations about registers in code_item. Alas, I don't know how to traverse them.

Another thought is, maybe we can retrieve type info from how registers are used, e.g., from method signature if used in invoke-* instructions, etc. But, this is still buggy, since we may want to know type info before it is indeed used.

Any suggestions?

[kuk0]

well, i don't know much about annotations...
can you do sth. like this

if (solve halting problem) { v0 <-- 42; } else { v0 <-- new Object(); }

in dex? i.e. can you use the same register for both ints and references?
because then (unless the type is clearly specified somewhere, say in annotations), inferring the type of register is undecidable...

one heuristic would be to ignore the zeros - zero is the only ambiguous value...

i actually needed to instrument methods just at the beginning, so i shifted the registers, used the free ones and then shifted all the parameters back to their original registers, so i didn't have to touch the rest of the code at all (but again, this is only possible if you add code at the very beginning....)

[kmicinski]

It seems like in general, the answer you want to this problem would be to use Redexer's live variable analysis to build a DU chain and then find the use of that definition. This can be implemented and it won't be too much of an issue, it will just take some time.