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
Can somebody, please, explain what is expected behaviour of the next steps:
Decompilers code pass in debug arg only pairs of (loc: var) for the symbolized version of function, not the pseudocode.
Then in preprocessors we performs filtering by output of pseudocode for both stripped and debug versions, resulting in critically large value loss, and nonpredictable rename model.
So, should be both pseudocode versions been involved, or not?
If not - would it be correct to perform filterring by keys() comparsion?
DIRTY only handles variable renaming and retyping, and recovering the code tokens for target side (debug version) is not part of the task.
Therefore, the only information we need from the target side to construct the learning task is its variables. The rest of the information in the debug version including other code tokens can't be used since they're not available during inference.
In preprocessing, for each variable in the source side (striped version), we try to match its target (corresponding variable in debug version).
Hello.
Can somebody, please, explain what is expected behaviour of the next steps:
Decompilers code pass in debug arg only pairs of (loc: var) for the symbolized version of function, not the pseudocode.
Then in preprocessors we performs filtering by output of pseudocode for both stripped and debug versions, resulting in critically large value loss, and nonpredictable rename model.
So, should be both pseudocode versions been involved, or not?
If not - would it be correct to perform filterring by keys() comparsion?
Thanks.
@huzecong @pcyin @clegoues @bvasiles @sophieball @qibinc
The text was updated successfully, but these errors were encountered: