C Instrumentation Framework

It would be great! But after update aspectator up to the new gcc with ldv pretty printer.

Another example is to share code that matches same kernel functions (e.g. spinlock or memory functions) between several rules/rule models.

The issue becomes more priority, since we're going to use aspectator more and more actively.

• @include
• @define

(I had to to use '@' instead of '$' to avoid conflicts with advice body patterns (like $argN, $ret_type, etc.))
This is rather considerable feature. So, I'm going to test it (especially with including of kernel function model of #2707) and merge to master.
At best neither this feature nor fixes of #2760 and #2954 shouldn't affect the standard workflow anyway.

There is at least one lack in the current implementation. For instance, when there is:

#include <linux/blkdev.h>

@include <linux/blkdev.h>

#define linux 1

#include <1/blkdev.h>

728e37f commit of feature-2958 fixed the issue. It's being tested and will be merged to master.

Merged to the master branch in commit 7775bfe.

More one problem was found by night tests: during aspect preprocessing '\'s are eliminated from aspects. This makes gcc unhappy, when there is such the construction is used in aspects:

#define LDV_CHECK_AND_INCREASE(state, value) ldv_assert(state == value); \
                                             state++;

Commit 41718a0 of the master branch fixed the issue in the following manner: it ignores all backslashes encountered in aspects. Because of this we cannot use backslashes in aspect defines, but still can use them in other cases. QA is running small tests now, big tests will be run at night.

More one issue was found by Denis Efremov. It turns out, that during aspect preprocessing modified preprocessor is called with options intended for a corresponding driver file compilation (preprocessing). This is totally incorrect since there may be such options that do not depend on presence of '#' directives and may affect on preprocessing. For instance:

-D name=definition
    The contents of definition are tokenized and processed as if they appeared during translation phase three in a `#define' directive. In particular, the definition will be truncated by embedded newline characters. 
    ...
-include file
    Process file as if #include "file" appeared as the first line of the primary source file. However, the first directory searched for file is the preprocessor's working directory instead of the directory containing the main source file. If not found there, it is searched for in the remainder of the #include "..." search chain as normal.

    If multiple -include options are given, the files are included in the order they appear on the command line.

Commit 983ce20 of the master branch should fix the given issue. Wait for QA will test this commit.

Again one more issue related! We use a hack to process typedefs at the beginning of function signatures, like:

around: call(#bool func(..))
{
...
}

around: call(
#bool func(..)
)
{
...
}

around: call(^bool func(..))
{
...
}

The given issue was fixed in commit c371769 of the master branch that is tested now.

Should be closed at last.

Close since there was not any objections.