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.
