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

[tromey at gcc dot gnu.org]

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

--- Comment #6 from Tom Tromey <tromey at gcc dot gnu.org> ---
(In reply to Josh Triplett from comment #4)

> Unfortunate, and I'd love to see GCC handle trailing attributes (does a bug
> already exist for that somewhere?), but not something that should block
> *this*
> feature.

Offhand I don't know if there is a bug covering this.

> (As a vaguely related aside, how does GCC disambiguate whether an attribute
> preceding the function declaration or definition applies to the return type
> or
> to the function?  I really hope that doesn't depend on the specific
> attribute.)

It does, see the various *_required fields in struct attribute_spec
(tree-core.h).  It's worse than you think, as I believe a given
attribute handler can decide where to put the attribute based on any
criteria it likes.

> Could you represent __context__ as a new GCC builtin?  Would that make this
> any
> easier?

It's basically the same thing.

One idea might be not to make the function const; then have the pass
rip out the calls to it.

However then you might have a situation where these calls formerly
interfered with some optimization, meaning that their presence did
affect code generation.  I don't really know if this is possible.

> Sparse actually tracks context as a property of basic blocks.

I was thinking this might be doable but I don't really know how
gcc handles basic block coalescing -- if two blocks are merged
we'd want to ensure that the resulting block ends up with the
correct context property.

It might help to see exactly where __context__ is used in real code.

> (if
> they ship it at all; AFAICT Debian only ships gcc-python3-plugin).

The version of python doesn't matter much.

For people whose distro doesn't package gcc-python-plugin, it is simple
to build; just git clone + make.

> So, I suspect the unfortunate answer is that Linux would probably want to
> ship
> the plugin as C/C++ and build it at build time if enabled.

That's also fine, it's easy(-ish) to rewrite.