Я пытаюсь использовать smali-код с помощью dexlib2, чтобы измерить охват ветвей. В частности, я вставляю в каждую ветвь (if и соответствующую метку) в основном две инструкции; const-string для загрузки уникальной трассировки для каждой ветки и invoke-static для вызова статического метода. Однако есть пара вопросов:
Во-первых, мне пришлось увеличить количество регистров на единицу. Это привело к перераспределению регистров некоторых инструкций, что, кажется, работает (используется отражение для увеличения номера регистра, например, изначально p0 получил v20, введя новый локальный регистр v21). Однако я заметил, что некоторые ярлыки, например. .end local v15 также потребует такого рода модификации, что кажется невозможным с dexlib2, поскольку метки не отслеживают ни такую информацию, ни имя. Я также не знаю, в чем смысл/намерение этих локальных меток .end/.restart./start. Интересны ли эти метки для сборки мусора или это какая-то информация о типе для соответствующих регистров?
Во-вторых, некоторые инструкции принимают в качестве аргументов только v0-v15. Вот почему мне пришлось различать, превышает ли количество локальных регистров 16 или нет. В этом случае я в основном использую две дополнительные инструкции перемещения: (в другом случае инструментарий намного проще)
move-object/16 vNew, v0 # сохранить значение v0
(две вышеупомянутые инструкции) # использовать v0 для сохранения трассировки
move-object/16 v0, vNew # восстановить значение v0
Однако недавно я получаю следующую ошибку (и аналогичные ошибки проверки):
[0x25C] «этот» аргумент «Ссылка: java.lang.Object», а не экземпляр «Ссылка: com.android.calendar.GeneralPreferences»
Я заметил, что есть разница между использованием move и move-object, но я не знаю о конкретной разнице. Я бы предположил, что константы не являются объектами, а остальные представляют собой объекты. Если это различие необходимо, мне пришлось бы выполнять некоторый анализ последнего типа v0 в каждой ветви, что еще больше усложняет ситуацию.
В-третьих, я заметил, что метки, связанные с ветвями, в некоторых редких случаях ведут себя несколько странно. Во всем файле smali есть ветки, которые инструментируются дважды. Отладка показывает, что запрос инструкции if для ее целевых меток (другая ветвь) один раз возвращает больше меток, чем в другой раз. Вот почему теперь я использую индекс целевой метки (instruction.getTarget().getLocation().getIndex()), но все равно получаю одну ветвь, которая обрабатывается дважды.
Я прошу любой помощи по этому конкретному вопросу, а также общих советов/фактов, которые я должен учитывать. Есть ли лучший способ получить более подробную информацию об ошибках; вывод logcat не самый лучший, например. какая конкретная инструкция вызвала ошибку проверки (шестнадцатеричное значение, рассматриваемое как offest, для меня не имеет никакого смысла).
Заранее спасибо.
