Less conservative control path analysis

[Baltoli]

When finding the set of functions that are 'control-reachable' from the bounding function, it shouldn't be too hard to ignore or filter the ones that can't affect the lock. The factors that go into this decision are:

• Is the lock variable global? If it is, any function can access it and everything on the control path needs to be considered.
• If it's not global, do any of the functions take a lock_t * (type of the asserted variable) as a parameter? If they do, then they should be considered.
• I think that it would be possible to be even more specific here, but would require chasing usages.

In theory it would be possible to circumvent this analysis by having a function take a void *, but is this bad enough behaviour in regard to aliasing that I can just ignore the possibility?

[Baltoli]

In fact this is a little more subtle - the called functions will cause an assertion failure even if they cannot access the lock (e.g. if it's a parameter), by calling lock_acquire or lock_release on another lock.

So it's not so easy to discount functions as described above - instead probably need a call graph.

[Baltoli]

Can we use the LLVM 3.4 CallGraph pass to do this?

[Baltoli]

In fact, this isn't what we want to be doing - any call to the acquire or release functions will cause a runtime error. This means that we don't want to discount paths where the actual lock variable couldn't reach itself, and so the current implementation is right.