[LLVMdev] Status of poolalloc, and in particular DSA
criswell at illinois.edu
Fri Dec 7 16:17:01 PST 2012
On 12/6/12 4:47 PM, Zvonimir Rakamaric wrote:
> Hi all,
> I've been using LLVM in my software analysis projects for quite a few
> years now, and several years back I relied on results of DSA analysis
> in my SMACK tool for checking C programs.
> At some point that part of SMACK got deprecated, but now I would like
> to revisit it since it was working quite well.
> Therefore, I would like to learn what's the status of the poolalloc
> project, and in particular its DSA analysis. I've seen there are
> regular commits, and also there is a branch called release_32, which
> is I presume following LLVM's 3.2 release. If that about right?
Correct. The release_32 branch of poolalloc works with the release_32
branch of LLVM (which should be the upcoming LLVM 3.2 to be released soon).
For the moment, we're not planning to have poolalloc trunk track LLVM
trunk until we're ready to move to the next LLVM version. However, that
policy decision is up for discussion, so if people need/want poolalloc
to track trunk, please email the list.
Regarding robustness, DSA should be working well. I used it when
compiling the DotGNU C# compiler earlier this year and got it to work.
As far as ability to infer types and disambiguate pointers, I am
unsure. I don't know when SMACK started using DSA, but we noticed a few
years ago that DSA's ability to infer types had diminished.
Investigation showed that some LLVM optimizations were changing typed
GEP instructions into byte-level GEP instructions, making type-inference
more difficult for DSA. The situation may have changed since then. My
recommendation is to try running DSA on a few programs to see if you're
getting the results you need.
> Basically, I would appreciate if somebody would comment if I can count
> on DSA being supported and following LLVM releases in the future.
DSA is currently maintained by our research group and is a necessary
component for making SAFECode's run-time checks stronger, so our current
plans call for continued maintenance of DSA. However, keep in mind that
we're an academic research group; we don't have the development
bandwidth of the entire LLVM community. If DSA is the best option for
your project, you may want to consider lending some time to helping us
-- John T.
> Thanks a lot!
> -- Zvonimir
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev