llvm dev - Apr 2011 - [LLVMdev] finding integer undefined behaviors using clang

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.

John

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

Thanks Nick-- this all sounds great!
> it looks like that's never used, only the clang::NoIntegerCheckAttr is 
> needed. Any reason to keep the llvm attribute around?
I doubt it, but will double check with Peng.
> Is there a repository with this code that I can hack on? Or what should I
do
> from here?
I'm not sure what's the best way to open up this patch for hacking, but
am
open to suggestions.

John