Fortunac/bap 2.0 upgrade

[fortunac]

Ports VSA and wp to BAP 2.0. Major changes include:

WP:

• no longer saving a BAP project in favor of a BAP program for binary diffing
• using the dummy binary as a way to determine the architecture
• using the last block of a sub to determine how much to increment SP rather than looking for a block with Ret since Ret has been removed

VSA:

• removing bounded_lcm in favor of Word.lcm_exn

[ivg]

There's no guarantee that the last block is the exit one. Neither that there's only one exit block. I would suggest implementing a simple dataflow analysis to compute the SP increments or use SSA to find it out.

[codyroux]

@ivg how about taking the minimal elements in the reverse topological order? Obviously it's still kind of a hack, but I'm not sure I've seen SP incremented across several blocks.

Also: I'm afraid I don't see how SSA helps here, can you explain?

[ccasin]

How is ret indicated in BAP 2.0? An explicit read from the stack and a jump?

[codyroux]

@ccasin I think it's a call with noreturn to the return address, if it's statically known.

[ivg]

@ivg how about taking the minimal elements in the reverse topological order? Obviously it's still kind of a hack, but I'm not sure I've seen SP incremented across several blocks.

Also: I'm afraid I don't see how SSA helps here, can you explain?

RTO won't work, because we can have many exit blocks. The best way to classify a block as an exit/return blocks is to look into it's out degree — if it is zero, i.e., no outcoming edges, then it is an exit block. After all exit blocks are identifed, you can fold over them to identify the maximum stack increment.

Concerning SSA, sorry it was a long train of thought, so let me elaborate :) A right and general solution for computing the frame size of a subroutine is to write an AI and compute the approximation of it. A simple dataflow analysis will already work, especially if we can ignore recursive functions. However, SSA already provides enough dataflow facts, so it can be used instead.

[codyroux]

@ivg thanks for the quick and detailed reply! My gut feeling is that we will:

1. Merge the current version of the code
2. Quickly implement a fix where we find return blocks using the heuristic you outlined
3. Longer term, implement the AI to determine the stack size of a call as a separate pass, maybe tagging the call site with the stack size, but we'll only do this when the simple heuristic starts to suffer.

How does this sound?

[codyroux]

All right! As far as I'm concerned, we can rebase whenever everyone's ready! Great job @fortunac !

[fortunac]

Sounds good! I'll work on the heuristic for finding the return blocks on a separate branch that we can merge in after this one.

[philzook58]

Everything looks good to me. I compiled and ran successfully ran make test on a bap:latest container. Good work!

[codyroux]

All right I'm pulling the trigger on this one, we'll roll back if there are issues.

[jtpaasch]

Didn't get a chance to run this yesterday, on account of being in 105 Broadway most of the day, but for Cody's sanity, Chloe's code does build on my machine, and tests pass, and conc2 builds too, using your fancy new BAP 2.0-friendly bap_wp.

[codyroux]

Thanks, JT. We've merged all this stuff, and we're exploring exciting new vistas of bap 2.0!

…

On Fri, Sep 6, 2019 at 10:04 AM JT Paasch ***@***.***> wrote: Didn't get a chance to run this yesterday, on account of being in 105 Broadway most of the day, but for Cody's sanity, Chloe's code does build on my machine, and tests pass, and conc2 builds too, using your fancy new BAP 2.0-friendly bap_wp. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#65?email_source=notifications&email_token=AA772UC3RLGC5Q2TNK726RTQIJPP7A5CNFSM4IRUP2E2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6C6GSI#issuecomment-528868169>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA772UGHNKZRV4C2FOM4763QIJPP7ANCNFSM4IRUP2EQ> .