SmPL Rule and An example:
PREQUISITES:
- configure git, setup linux drivers on local machines
- Set up email client using mutt or git to submit patches to liunx.org
- Install Coccinelle packages
PROCEDURE TO WRITE COCCINELLE SCRIPTS:
Before creating cociinelle scripts we first understand what is coccinelle and its use.
What is Coccinelle ?
- When C Programs are written we often find errors, warnings, dead code, unnecessary functions, uninitialised variables, Memory leaks (malloc, kmalloc) and detection of problematic programming patterns.
- It becomes difficult to fix each and every bug repeatedly in C files.
So coccinelle enables us to automate the process of bug fixing using SmPL(Semantic Patch Language) for specifying desired matches and modify the code according to the kernel standards.
Coccinelle is a tool to automatically analyze and rewrite C code.(SMPL)
We have some rules before we generate semantic patches and run on C files.
A DESCRIPTIVE EXAMPLE ON HOW SmPL WORKS:
Rules describe a property that Coccinelle should match and when property is matched then rule is considered successfull
USING DOTS:
Ellipses (“...”) are used to indicate that anything can be present between consecutive statements.
For example the following SmPL patch tells Coccinelle that rule r0 wishes to remove all calls to function c().
1 @r0@
2 @@ 3 4 -c();
We have some rules before we generate semantic patches and run on C files.
A DESCRIPTIVE EXAMPLE ON HOW SmPL WORKS:
Rules describe a property that Coccinelle should match and when property is matched then rule is considered successfull
USING DOTS:
Ellipses (“...”) are used to indicate that anything can be present between consecutive statements.
For example the following SmPL patch tells Coccinelle that rule r0 wishes to remove all calls to function c().
1 @r0@
2 @@ 3 4 -c();
The context of the rule specifies that no other guidelines to Coccinelle about any possible control flow other than this is a statement, and that c() must be called.
We can modify the required control flow required for this rule by providing additional requirements and using ellipses in between.
For instance, if we only wanted to remove calls to c() that also had a prior call to foo() we’d use the following SmPL patch:
We can modify the required control flow required for this rule by providing additional requirements and using ellipses in between.
For instance, if we only wanted to remove calls to c() that also had a prior call to foo() we’d use the following SmPL patch:
1 @r1@
2 @@
3
4 foo()
5 ...
6 -c();
|
There are two possible modifiers to the control flow for ellipses:
1. (<... ...>) indicates that matching the pattern in between the ellipses is optional,
2. (<+... ...+>) indicates that the pattern in between the ellipses must be matched at least once, on some control-flow path.
In the latter, the + is intended to be reminiscent of the + used in regular expressions.
For instance, the following SmPL patch tells Coccinelle to remove all calls to c(). if foo() is present at least once since the beginning of the function.
Alternatively, the following indicates that foo() is allowed but optional. This case is typically most useful when all occurrences, if any, of foo() prior to c() should be transformed.
1. (<... ...>) indicates that matching the pattern in between the ellipses is optional,
2. (<+... ...+>) indicates that the pattern in between the ellipses must be matched at least once, on some control-flow path.
In the latter, the + is intended to be reminiscent of the + used in regular expressions.
For instance, the following SmPL patch tells Coccinelle to remove all calls to c(). if foo() is present at least once since the beginning of the function.
1 @r2@
2 @@
3
4 <+...
5 foo()
6 ...+>
7 -c();
|
1 @r3@
2 @@
3
4 <...
5 foo()
6 ...>
7 -c();
|
Example: sample.c
1
2 int main(void)
3 {
4 int ret, a = 2;
5
6 a = foo(a);
7 ret = bar(a);
8 c();
9
10 return ret;
11 }
|
Applying the SmPL rule r0 to flow1.c would remove the c() line as the control flow provides no specific context requirements. Applying rule r1 would also succeed as the call to foo() is present. Likewise rules r2 and r3 would also succeed. If the foo() call is removed from sample.c only rules r0 and r3 would succeed, as foo() would not be present and only rules r0 and r3 allow for foo() to not be present.
Comments
Post a Comment