Re: [cocci] List global variables with SmPL

[Alessandro Carminati <alessandro.carminati@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5272 bytes --]

Hello Julia,
I modified the coccinelle script in accordance with your suggestions (at
least, my understanding of those).
The script I'm currently using is like this:
```
@excluded@
type T;
identifier i;
position p;
@@

(
 T i@p(...);
|
 extern T i@p;
)


@r@
type T;
identifier i;
expression E;
position q != excluded.p;
position p : script:python(i) { p[0].current_element == i};
@@

(
 T i@q@p;
|
 T i@q@p=E;
)

@script:python@
i << r.i;
@@
print (i)
```
The rule "excluded" should find what I need to be excluded.
Still, the script has trouble with statements like this:
```
__printf(3, 4) __cold
void _dev_printk(const char *level, const struct device *dev,
                 const char *fmt, ...);
```
And it reports "_dev_printk" as a global variable.
There are also problems with some "__randomize_layout" statements, but I've
not yet isolated the minimal statement that can report "__randomize_layout"
as the global variable name.
My assumption is that I can add defines as done in the init_defs_builtins:
/usr/local/lib/coccinelle/standard.h, but using the -define argument with a
file containing these defines does not solve the problem.
Sorry for keeping this thread long, but your advice would be very
appreciated.

cheers
Alessandro



Il giorno mar 10 mag 2022 alle ore 10:06 Julia Lawall <julia.lawall@inria.fr>
ha scritto:

>
>
> On Tue, 10 May 2022, Alessandro Carminati wrote:
>
> > Hello Markus,
> >
> >
> > Il giorno lun 9 mag 2022 alle ore 21:23 Markus Elfring
> > <Markus.Elfring@web.de> ha scritto:
> >
> >             The solution you sent indeed does what I expected.
> >
> >
> > I doubt that it fits to your initial source code analysis desire.
> >
> > Are your expectations still evolving (also for your data processing
> > needs)?
> >
> > Indeed Julia's proposed code does not solve all the situations I
> encounter
> > now  in the kernel source analysis.
> > It reports not only global variable names but also function names.
> > It confuses sparse annotation and a few other macros with variable names.
> > I also have trouble with "extern" declared variables that appear multiple
> > times.
> > Still, it is far better than I was up to, And it allows me to improve the
> > solution by adding statements and rules to make it better suit my use
> case.
> > Currently, I'm using this, but I still have duplicates due to "extern"
> > declarations.
> > ```
> > @func@
> > type T;
> > identifier i;
> > position p : script:python(i) { p[0].current_element == i};
> > @@
> >
> > T i(...)@p;
> >
> >
> > @r depends on !func@
> > type T;
> > identifier i;
> > expression E;
> > position p : script:python(i) { p[0].current_element == i};
> > @@
>
> Thanks for the feedback.  The strategy of !func is a good idea, but it is
> not correct.  There is no particular relation between the func rule and
> this one.  Thus as soon as a file contains code that matches the func
> rule, the file will be ignored.
>
> One solution would be to check that the position of i is not the same as
> the position of a name matched by the func rule.  For that, you could move
> the @p in the func rule from the ) to the function name, and then in this
> rule put as the first metavariable line:
>
> position q != func.p;
>
> and then in the matches below put i@q@p (ensure that is at a position
> that is both different than any func.p and that it satisfies the
> current_element constraint).
>
> But in this case, there is a solution that is even simpler:
>
> (
> T i(...);
> |
> T i@p;
> |
> T i@p=E;
> )
>
> Indeed, I think it should be sufficient to say:
>
> (
> T i(...);
> |
> T i@p=...;
> )
>
> You can run spatch --parse-cocci to see what happens with the rewriting
> due to isomorphisms to see if the simpler rule is sufficient.
>
> Or maybe you want:
>
> (
> T i(...);
> |
> extern T i;
> |
> T i@p=...;
> )
>
>
> >
> > (
> >  T i@p;
> > |
> >  T i@p=E;
> > )
> >
> > @script:python@
> > i << r.i;
> > @@
> > print (i)
>
> Maybe you also want to inherit the position variable and print the file
> and line number of the declaration?
>
> julia
>
> > ```
> >
> >
> >
> >             Would you mind add a short explanation of this
> >             statement:
> >             `position p : script:python(i) {
> >             p[0].current_element == i};`
> >             I probably have a simplified understanding of what a
> >             position is.
> >
> > I imagine that known information sources can help further.
> >
> >
> https://gitlab.inria.fr/coccinelle/coccinelle/-/blob/5069eaeadd731ecdd99e7a
> > 6f4465c286a2792354/docs/manual/cocci_syntax.tex#L410
> >
> https://github.com/coccinelle/coccinelle/blob/ae337fce1512ff15aabc3ad5b6d2e
> > 537f97ab62a/docs/manual/cocci_syntax.tex#L410
> >
> > Thanks for this.
> >
> >
> >
> >
> >             Maybe it is worth digging deeper and having a more
> >             concrete knowledge.
> >
> >
> > Probably, yes.
> >
> >
> >
> >       Any read you want to suggest to me?
> >
> >
> > Related links for example:
> >
> >
> https://gitlab.inria.fr/coccinelle/coccinelle/-/blob/5069eaeadd731ecdd99e7a
> > 6f4465c286a2792354/docs/Coccilib.3cocci#L5
> >
> https://github.com/coccinelle/coccinelle/blob/57cbff0c5768e22bb2d8c20e8dae7
> > 4294515c6b3/docs/Coccilib.3cocci#L5
> >
> >
> >
> > Regards,
> > Markus
> >
> >
> >

[-- Attachment #2: Type: text/html, Size: 7593 bytes --]