You are right that our current proposal/implementation doesn't handle
indirect function calls. (And we didn't try to do any pointer/alias
analysis for variables either in our first implementation .) But the
analysis will not be disabled completely if it encounters an indirect
function call. It simply ignores the indirect call. For example, when
analyzing function "foo" in the following code,
Mutex mu1, mu2;
int g GUARDED_BY(mu1);
void bar() EXCLUSIVE_LOCKS_REQUIRED(mu2);
int foo(int x, void (*indirect_func)())
{
mu1.Lock();
indirect_func();
g = x + 2;
mu1.Unlock();
}
main()
{
foo(3, bar);
...
}
the analyzer will not be able to check the lock requirements for
"indirect_func", but it will continue to check whether writing to
variable "g" is indeed guarded by "mu1".
I think we tried to make the initial version of the
annotations/analysis simple so that users won't get too intimidated by
a very complex annotation system that covers all the cases. But
certainly it will be extended in the future. (Supporting the function
pointers/indirect calls is certainly one of the enhancements to
consider.)
Thanks,
Le-chun
On Mon, Jun 9, 2008 at 8:33 PM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> "Le-Chun Wu" <[EMAIL PROTECTED]> writes:
>>
>> Please let me know if you have any feedback/comments/questions on the
>> proposed annotations and the GCC implementation.
>
> I was surprised that there was no consideration of C indirect function
> calls in your design document. e.g. I would have expect some way
> to give a hint that a indirect function call is always called from X
> to propagate the lock sets. Right now it looks like they will
> disable the analysis completely, correct?
>
> -Andi
>
>
