You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I just notice that the compute_static_layout runs slower than expected. Upon further investigation, I noticed it collects the basic blocks of the functions. And in the binja extractor, when we return the list of basic blocks, we request the MLIL of the function to pair the disassembly bbl and MLIL bbl.
I think this is actually worse than the previous implementation, i.e., before e9d4a23. although before that commit, there is actually an O(n^2) lookup on the MLIL basic blocks. However, thanks to the recent effort to optimize the performance, it is discovered that the MLIL is not causing a lot of issues. Also, since n is the number of the basic blocks, it should usually just be fine.
Better still, I think there is a different way to do it. We can just do the stack string detection on the function level, rather than at the basic block level. In this way, we would only need to enumerate the MLIL basic blocks once. Do you think this would work? @williballenthin