llvm dev - Dec 2012 - [LLVMdev] Status of poolalloc, and in particular DSA

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?

Basically, I would appreciate if somebody would comment if I can count
on DSA being supported and following LLVM releases in the future.

Thanks a lot!

-- Zvonimir

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 
maintain it.

-- John T.
> Thanks a lot!
>
> -- Zvonimir
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu          http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Fri, Dec 7, 2012 at 5:17 PM, John Criswell <criswell at illinois.edu>
wrote:
> On 12/6/12 4:47 PM, Zvonimir Rakamaric wrote:
>>
>> 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.
Sorry I wasn't clear here...
I am perfectly fine that poolalloc tracks LLVM releases. In fact,
that's what I am planning to do with SMACK and just track LLVM
releases and not LLVM trunk. So that should work well for me, and
there is no need to follow LLVM trunk.
> Regarding robustness, DSA should be working well.  I used it when compiling
> the DotGNU C# compiler earlier this year and got it to work.
Awesome!
> 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.
Thanks for the info. Yes, I'll definitely give it a try...
>> 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
That's the main thing I wanted to hear. It somewhat assures me that my
investment into using DSA again won't go down the drain as soon as
LLVM moves ahead a release or two....
> 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 maintain it.
For sure! I am in academia myself, so I know how things are.
In fact, we are looking to hire a programmer who is familiar with LLVM
to help us with this and other similar efforts (we use LLVM a lot in
our tools). So if you know anybody who fits that profile and is
interested to work on challenging problems in a research environment,
please feel free to pass them my contacts.

Thanks John!

Best,
-- Zvonimir