Patch and documentation can be found here:
John
It seems that this could be merged into -fcatch-undefined-behavior while separating mechanism from policy:
1) Adding checks for more undefined behavior.
2) Allowing different choices of trap mechanism when undefined behavior is encountered.
Cameron
I forgot to say that this is nice work. A lot of people don't even know about undefined behavior like this, and it is hard to catch it while you are programming even if you do know about it.
Cameron
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