Inconsistent behavior of get_var_uses between Medium and High Level IL
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 30/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
Direzione di ricerca
Reproduce the behavior through the MLIL and HLIL get_var_uses entry points shown in the issue, comparing whether each returns instructions or expressions and whether definitions are included. Trace the corresponding API implementation and add coverage for the reported variable-use case; done means HLIL behavior is consistent with MLIL or returns only read uses as documented.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Binary Ninja Version
Version 2.4.3081-dev Personal
Describe the bug
Split out from a previous conversation in slack. In MLIL, get_var_uses returns instructions where the passed-in argument is on the RHS.
>>> current_mlil.get_var_uses(state_var_mlil)
[<mlil: rax_1 = var_1c>]
However in HLIL, get_var_uses returns expressions instead of instructions, including those expressions which appear in the LHS of that instruction (i.e. writes/definitions).
>>> current_hlil.get_var_uses(state_var_hlil)
[<HLIL_VAR: var_1c>, <HLIL_VAR: var_1c>, <HLIL_VAR: var_1c>, <HLIL_VAR: var_1c>, <HLIL_VAR: var_1c>, <HLIL_VAR: var_1c>, <HLIL_VAR: var_1c>, <HLIL_VAR: var_1c>]
I was upgrading some old code from using mlil to hlil and was confused when my code using get_var_uses() stopped working because it returned expressions instead of instructions, and returned far more results than expected.
Expected behavior
current_hlil.get_var_uses should return instructions instead of expressions, or at least return only the expressions which are reads/uses
Version and Platform (required):
- Binary Ninja: Version 2.4.3081-dev Personal
- OS: Windows
- Version 10
- Lingua principale
- C++
- Stelle
- 1.3k
- Fork
- 298
- Merge medio
- 5g 5h
- PR unite (30g)
- 19
Guida per i contributori
Nessuna guida per i contributori indicizzata per questo repository
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di Vector35/binaryninja-api
-
Difficoltà 1/5 1-3 ore Idoneità per principianti 88/100
Vector35/binaryninja-api#8540 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
Vector35/binaryninja-api#8516 ·
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 92/100
Vector35/binaryninja-api#8503 ·
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
Vector35/binaryninja-api#8446 ·
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
Vector35/binaryninja-api#8444 ·
Tutte le issue di Vector35/binaryninja-api
Issue simili
-
Difficoltà 1/5 1-3 ore Idoneità per principianti 92/100
autowarefoundation/autoware_universe#13413 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
-
automated-analysis bug memory-safety
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
-
Sensor initialization takes very long when `--initial-sim-time` is set to current UNIX timestamp Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
gazebosim/gz-sensors#662 · 1 commento ·