Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: What's the best practice to write analysis based on relations generated by ddisasm? #42

Open
5c4lar opened this issue Feb 10, 2022 · 2 comments

Comments

@5c4lar
Copy link
Contributor

5c4lar commented Feb 10, 2022

I'm trying to write some analysis with datalog based on ddisasm, but it's not convenient to reuse the existing results when implementing a pass. Should I write some datalog program and include it from main.dl or are there any recommended ways?

@5c4lar 5c4lar closed this as completed Feb 14, 2022
@aeflores aeflores reopened this Mar 8, 2022
@aeflores
Copy link
Collaborator

aeflores commented Mar 8, 2022

Hi @ucasqsl, I see you started adding code as a pass in the passes directory. This is certainly a feasible approach. However, we are currently working on an alternative way to allow users to leverage existing results of ddisasm in a way that is decoupled from the main ddisasm code.

Currently, you can run ddisasm with --with-souffle-relations, which will store all the output relations of the souffle program into an AuxData table in the gtirb file. Thus, you could have a standalone module that loads the gtirb and extracts those relations as facts for your own analysis. What we are trying to do next is to more clearly define which relations are "public" (and relatively stable) which are "private" (can change anytime). This way, downstream analyses won't break with every change that we do in the main ddisasm code.

We will post updates in this issue.

@5c4lar
Copy link
Contributor Author

5c4lar commented Mar 9, 2022

Currently, you can run ddisasm with --with-souffle-relations, which will store all the output relations of the souffle program into an AuxData table in the gtirb file. Thus, you could have a standalone module that loads the gtirb and extracts those relations as facts for your own analysis. What we are trying to do next is to more clearly define which relations are "public" (and relatively stable) which are "private" (can change anytime). This way, downstream analyses won't break with every change that we do in the main ddisasm code.

Thanks, this info is helpful, if I've ever read that option more closely, I think I'd use it. Looking forward to the updates.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants