Re: [cocci] List global variables with SmPL

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

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

Sorry for this.
the script is:

```
@excluded@
type T;
identifier i;
position p;
@@

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


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

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

@rr@
type T;
identifier i;
expression E;
attribute name __randomize_layout;
@@

(
 T i;
|
 T i=E;
)

@script:python@
i << r.i;
@@
print (i)
```
the target file is
https://raw.githubusercontent.com/torvalds/linux/master/sound/soc/mediatek/common/mtk-afe-platform-driver.c
and the symbol I'm looking for is mtk_afe_pcm_platform
I introduced the rule rr to attempt to debug the script. It is not meant to
be part of the final script.
Thank you for the help.

Alessandro


Il giorno mer 11 mag 2022 alle ore 09:44 Julia Lawall <julia.lawall@inria.fr>
ha scritto:

>
>
> On Wed, 11 May 2022, Alessandro Carminati wrote:
>
> > I'm planning to stop bugging this mailing list, but before that, please
> allow me a final question. That is related to what I have done so far.
> > My current implementation is the following.
> > ```
> > @excluded@
> > type T;
> > identifier i;
> > position p;
> > @@
> >
> > (
> >  T i@p(...);
> > |
> >  extern T i@p;
> > |
> >  T i@p(...,......);
> > )
> >
> >
> > @r@
> > type T;
> > identifier i;
> > expression E;
> > position q != excluded.p;
> > position p : script:python(i) { p[0].current_element == i};
> > attribute name __randomize_layout;
> > @@
> >
> > (
> >  T i@q@p;
> > |
> >  T i@q@p=E;
> > )
> >
> > @rr@
> > type T;
> > identifier i;
> > expression E;
> > attribute name __randomize_layout;
> > @@
> >
> > (
> >  T i;
> > |
> >  T i=E;
> > )
> >
> > @script:python@
> > i << excluded.i;
> > @@
> > print (i)
> > ```
> > It is a suboptimal version of Julia's last proposition.
> > It happens that in a file a statement I expect to be matched is not
> detected.
> > Troubleshooting the issue, I see a behavior that does not fit the model
> I have in my mind. This suggests to me that things (coccinelle under the
> hood mechanisms) are more complicated than I think.
> > back to the point:
> > Running the script and printing only the rule "rr", which is the same as
> "r" without positions, the results presents a set of entries containing the
> entry I'm interested in.
> > Running the same script but printing only the rule "excluded", I see
> that the result is an empty set.
> > Finally, running the script using only the "r" rule, the entry I'm
> interested in is not there.
> > Surprisingly (for me), removing the position constraints coming from the
> rule "excluded" (position q != excluded.p;) from the rule "r", the entry
> appears.
> > My question then is the following: How can the rule "excluded" that
> presents an empty set influence the rule "r"?
> > Speculating Julia's words on a previous answer I got, I guessed that
> somehow an empty set could be treated differently, so I added a line into
> the target c file to make at least "excluded" match one line. But it didn't
> make any difference.
>
> Sorry, but I can't answer a question at that abstract level.  Please send
> the precise example (semntic patch and code), and I will check on what
> went wrong.
>
> julia
>
> >
> > Alessandro
> >
> >
> >
> > Il giorno mar 10 mag 2022 alle ore 12:39 Julia Lawall <
> julia.lawall@inria.fr> ha scritto:
> >       Here is a suggested solution for all of the problems reported so
> far:
> >
> >       @r@
> >       type T;
> >       identifier i;
> >       expression E;
> >       position p : script:python(i) { p[0].current_element == i };
> >       attribute name __randomize_layout;
> >       @@
> >
> >       (
> >       T i(...);
> >       |
> >       T i(...,......);
> >       |
> >       extern T i;
> >       |
> >       T i@p;
> >       |
> >       T i@p=E;
> >       )
> >
> >       @script:python@
> >       i << r.i;
> >       p << r.p;
> >       @@
> >       print (i)
> >
> >       ----------------------
> >
> >       The problem with __randomize_layout is that the Coccinelle parser
> is not
> >       recognizing it as an attribute.  You can force that by putting a
> >       declaration in the semantic patch.
> >
> >       It seems that ... in a function parameter list does not match the
> ... in C
> >       for a variable list of arguments.  That ... can be matched
> explicitly by
> >       ...... so I have added another case with that.
> >
> >       I als combined all of the patterns into one rule.  By inheriting
> the
> >       position varaible p into the python rule at the end, that python
> rule is
> >       only executed if p is defined, which makes it select the cases of
> interest
> >       and ignore the others.
> >
> >       julia
> >
> >
> >

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