[Cocci] Support for macro expansion

[Cocci] Support for macro expansion

[Martijn Coenen]

Hello,

I can't find a clear-cut answer on whether macro expansion is supported in
Coccinelle. There's a "--preprocess" option which says it runs the C
preprocessor before doing the match, but it didn't appear to do anything
when I tried it.

Background: I'm trying to do a semantic patch that is only applied when a
certain function is called or assigned. Unfortunately in some cases, the
function call is embedded in a macro, and so Coccinelle will not find it.
I'm aware I can manually define a macros file and have it expanded this
way, but I want to make this as generic as possible and have it work for
any function in the linux kernel - which means I'd have to put *lots* of
macros in there :)

Any suggestions?

Thanks,
Martijn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://systeme.lip6.fr/pipermail/cocci/attachments/20180112/937efc44/attachment.html>

[Cocci] Support for macro expansion

[Julia Lawall]

On Fri, 12 Jan 2018, Martijn Coenen wrote:

> Hello,
> I can't find a clear-cut answer on whether macro expansion is supported in
> Coccinelle. There's a "--preprocess" option which says it runs the C
> preprocessor before doing the match, but it didn't appear to do anything
> when I tried it.
>
> Background: I'm trying to do a semantic patch that is only applied when a
> certain function is called or assigned. Unfortunately in some cases, the
> function call is embedded in a macro, and so Coccinelle will not find it.
> I'm aware I can manually define a macros file and have it expanded this way,
> but I want to make this as generic as possible and have it work for any
> function in the linux kernel - which means I'd have to put *lots* of macros
> in there :)
>
> Any suggestions?

Is it possible to parse the macro? That is, is the body a legal C
statement or expression?

Normally, macros are only unfolded when doing so is necessary to parse the
context in which the macro occurs.  But when a macro is unfolded for that
reason, it is not possible to transform the unfolded code, although it is
possible to match it.

It is indeed possible that the --preprocess argument does not do anything.

julia

[Cocci] Support for macro expansion

[Martijn Coenen]

On Fri, Jan 12, 2018 at 7:50 PM, Julia Lawall <julia.lawall@lip6.fr> wrote:
>
> Is it possible to parse the macro? That is, is the body a legal C
> statement or expression?

The macro I was looking at is module_usb_serial_driver():

https://elixir.free-electrons.com/linux/v4.15-rc7/source/include/linux/usb/serial.h#L433

The macro itself expands to another macro (maybe that is the
problem?), which expands to a few C function definitions. In this case
I was interested in seeing whether a file used the
"usb_serial_register_drivers()" function, which is called in one of
those function definitions.

Thanks,
Martijn

>
>
> Normally, macros are only unfolded when doing so is necessary to parse the
> context in which the macro occurs.  But when a macro is unfolded for that
> reason, it is not possible to transform the unfolded code, although it is
> possible to match it.
>
> It is indeed possible that the --preprocess argument does not do anything.
>
> julia

[Cocci] Support for macro expansion

[Julia Lawall]

On Fri, 12 Jan 2018, Martijn Coenen wrote:

> On Fri, Jan 12, 2018 at 7:50 PM, Julia Lawall <julia.lawall@lip6.fr> wrote:
> >
> > Is it possible to parse the macro? That is, is the body a legal C
> > statement or expression?
>
> The macro I was looking at is module_usb_serial_driver():
>
> https://elixir.free-electrons.com/linux/v4.15-rc7/source/include/linux/usb/serial.h#L433
>
> The macro itself expands to another macro (maybe that is the
> problem?), which expands to a few C function definitions. In this case
> I was interested in seeing whether a file used the
> "usb_serial_register_drivers()" function, which is called in one of
> those function definitions.

The easiest thing would be to just extend your semantic patch to look for
uses of module_usb_serial_driver.  module_usb_serial_driver however is
called outside of any function.  So you need to make a declaration among
the metavariables:

declarer name module_usb_serial_driver;

It doesn't make it ia metavariable, but rather gives some information
about the name so that it will look for this name at top level.

julia


>
> Thanks,
> Martijn
>
> >
> >
> > Normally, macros are only unfolded when doing so is necessary to parse the
> > context in which the macro occurs.  But when a macro is unfolded for that
> > reason, it is not possible to transform the unfolded code, although it is
> > possible to match it.
> >
> > It is indeed possible that the --preprocess argument does not do anything.
> >
> > julia
>

[Cocci] Support for macro expansion

[Martijn Coenen]

On Sat, Jan 13, 2018 at 7:46 AM, Julia Lawall <julia.lawall@lip6.fr> wrote:
> declarer name module_usb_serial_driver;
>
> It doesn't make it ia metavariable, but rather gives some information
> about the name so that it will look for this name at top level.

Thanks, I'll give this a shot. But say I wanted to do this for any
random function in the linux kernel; in that case I would have to
manually declare all macros that contain any of those functions? In
other words, there's not really a way to write something that works
for any function (passed as a virtual to the .cocci)?

Thanks,
Martijn

>
> julia
>
>
>>
>> Thanks,
>> Martijn
>>
>> >
>> >
>> > Normally, macros are only unfolded when doing so is necessary to parse the
>> > context in which the macro occurs.  But when a macro is unfolded for that
>> > reason, it is not possible to transform the unfolded code, although it is
>> > possible to match it.
>> >
>> > It is indeed possible that the --preprocess argument does not do anything.
>> >
>> > julia
>>

[Cocci] Support for macro expansion

[Julia Lawall]

On Mon, 15 Jan 2018, Martijn Coenen wrote:

> On Sat, Jan 13, 2018 at 7:46 AM, Julia Lawall <julia.lawall@lip6.fr> wrote:
> > declarer name module_usb_serial_driver;
> >
> > It doesn't make it ia metavariable, but rather gives some information
> > about the name so that it will look for this name at top level.
>
> Thanks, I'll give this a shot. But say I wanted to do this for any
> random function in the linux kernel; in that case I would have to
> manually declare all macros that contain any of those functions? In
> other words, there's not really a way to write something that works
> for any function (passed as a virtual to the .cocci)?

My impression is that the problem arises only rarely.

It's hard for Coccinelle to know what macros you want to be expanded.
Also Coccinelle doesn't necessarily have access to the definitions of the
macros, unless you use eg --recursive-includes, which will massively
increase the amount of code to process and correspondingly degrade the
performance.  The idea is that generally it is beneficial to reason about
the code in the way that you see it, ie with the macro calls in the code
as they are.

julia


>
> Thanks,
> Martijn
>
> >
> > julia
> >
> >
> >>
> >> Thanks,
> >> Martijn
> >>
> >> >
> >> >
> >> > Normally, macros are only unfolded when doing so is necessary to parse the
> >> > context in which the macro occurs.  But when a macro is unfolded for that
> >> > reason, it is not possible to transform the unfolded code, although it is
> >> > possible to match it.
> >> >
> >> > It is indeed possible that the --preprocess argument does not do anything.
> >> >
> >> > julia
> >>
>

[Cocci] Support for macro expansion

[Martijn Coenen]

On Mon, Jan 15, 2018 at 10:14 AM, Julia Lawall <julia.lawall@lip6.fr> wrote:
> The idea is that generally it is beneficial to reason about
> the code in the way that you see it, ie with the macro calls in the code
> as they are.

Yes, I think that makes sense - what I'm trying to do is sort of an
edge case. Thanks for your help.

Martijn

>
> julia
>
>
>>
>> Thanks,
>> Martijn
>>
>> >
>> > julia
>> >
>> >
>> >>
>> >> Thanks,
>> >> Martijn
>> >>
>> >> >
>> >> >
>> >> > Normally, macros are only unfolded when doing so is necessary to parse the
>> >> > context in which the macro occurs.  But when a macro is unfolded for that
>> >> > reason, it is not possible to transform the unfolded code, although it is
>> >> > possible to match it.
>> >> >
>> >> > It is indeed possible that the --preprocess argument does not do anything.
>> >> >
>> >> > julia
>> >>
>>