[LLVMdev] finding integer undefined behaviors using clang
Nick Lewycky
nicholas at mxc.ca
Sun Apr 10 23:30:54 PDT 2011
John Regehr wrote:
> Hi Cameron,
>
> I agree, it would be nice to integrate this. My quick analysis of the
> situation, however, was that there's probably some difference of opinion
> about how heavyweight the trap handler should be. Ours is very heavy, in
> order to produce informative messages. People using traps in production
> code -- for example to simulate infinitely-ranged integers -- aren't going
> to like this. It's probably possible to engineer a solution that makes
> everyone happy, but it may be quite a bit of work.
>
> In the meantime I wanted to get our code out there so people can use it.
> My hope is that if it turns out to be valuable, someone more conversant
> with LLVM will figure out how it fits into the bigger picture.
Yes, I want to use this and would like to see it land in clang upstream.
I don't think you need the llvm patch. That allows us to mark the
llvm::Functions as having the 'nointegercheck' attribute applied to
them, but it looks like that's never used, only the
clang::NoIntegerCheckAttr is needed. Any reason to keep the llvm
attribute around?
Then the trap handler looks simple enough that it could go into clang's
lib/runtime. It's not clear to me what to do about the hashtable and
mersenne twister; things in lib/runtime should provide a C interface but
I think we can write it in C++ and make use of C++ and LLVM's existing
facilities. Then clang should statically link the programs against the
trap handler when the catch-undefined-... flags are provided.
I'm not worried about making a light-weight trap handler replacement
just yet because I see this as a testing tool that doesn't go into
production binaries. Creating one that does seems to be a separate
problem to me.
Is there a repository with this code that I can hack on? Or what should
I do from here?
Nick
More information about the llvm-dev
mailing list