blob: 9dc0bbff2009e14554528e40dc7550a0bf4f41a1 [file] [log] [blame]
cocci-tact: Demo for instrumenting with Coccinelle
This is a basic demo to show how one can do instrumentation with Coccinelle.
The problem
Some Linux kernel debugging features often require adding a lot of debug data
structures to a source code repository, often this is addressed with
CONFIG_DEBUG_* features but sometimes maintaining this upstream on Linux is not
really welcomed due to how intrusive your changes may be or the difficulty
in maintaining it properly. Sometimes such code can simply increase the
complexity of what developers see, and can often riddle developers how to
address its use / extending it / or replacing your instrumentation code.
Instrumenting with Coccinelle
Coccinelle enables a possible alternative: modify upstream code only when
you need it, for a throw away debugging kernel. Your instrumentation then
can be compartamentalized as much as possible upstream, and changes to
existing code kept separate, outside of what developers see.
This demo illustrates adding some form of instrumentation basic templates
to code in userspace by trying to take advantage of a simple line which
would be assumed to be upstream: on code pthread_mutex_protects_3().
In this case pthread_mutex_protects_3() provides Coccinelle with hints
over what data structures a mutex protects. It is the goal of the
instrumentation mechanisms being developed here to either fix or
debug this code without affecting readability for users or average
developers of the code.
This demo is written in userspace to help facilitate testing of ideas.
Instrumentation ideas are not yet complete but its the hope this provides
enough examples to show how this sort of work might look like. Locking
would just be one area that could use this. There are obviously other
domains that could benefit from this.
* Coccinelle >= 1.0.2
* gcc
* make
To see the problem run:
To see what the instrumentation does:
make coccicheck
git diff
This doesn't do anything quite useful just yet.