[Bug c/59856] Support sparse-style context checking, used to validate locking correctness

["pageexec at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59856

--- Comment #19 from PaX Team <pageexec at gmail dot com> ---
(In reply to Josh Triplett from comment #18)
> (In reply to PaX Team from comment #17)
> > (In reply to Josh Triplett from comment #16)
> > speaking of generalization, the encoding of the lock expression (e.g., lock
> > ptr) will have to change as it really doesn't seem feasible to refer to
> > function arguments from an attribute.
> 
> Doesn't seem too unreasonable to handle, actually.  When parsing an
> attribute, refer back to the function arguments; the context expression must
> either use those or globals.

the problem is that gcc itself refuses to parse an expression that wants to
refer to a function argument (global variables work fine). this is something
that changed with gcc-5, previously such a reference would at least produce an
identifier_node (basically just the name of the referenced parameter but
without any reference to the parm_decl itself, so not too useful), now it's a
compile error:

 error: 'p' undeclared here (not in a function)

so getting this to work would require frontend patches at least (and is beyond
what a plugin can do but see below for an idea).

> That fails for a really common case that should generate a warning:
> 
> spin_lock(&some_lock);
> /* Piles of code */
> spin_unlock(&some_other_lock);

hmmm, true, so some parsing is inavoidable. the stringification idea may still
be viable however as the attribute parsing code runs as part of the frontend so
technically it has access to the parsing machinery and could perhaps extract at
least simple expressions (or just a function argument) from the string. i'll
make some experiments and see if i can get back a reference to a parm_decl at
least.