From: Julia Lawall <julia.lawall@inria.fr>
To: Luca Coelho <luca@coelho.fi>
Cc: Markus Elfring <Markus.Elfring@web.de>, cocci@inria.fr
Subject: Re: [cocci] Searching for special function implementations with SmPL
Date: Mon, 30 Jan 2023 09:56:27 +0100 (CET) [thread overview]
Message-ID: <2fecadea-70f4-d4c0-d280-8776e5e12cb1@inria.fr> (raw)
In-Reply-To: <13bf65ac8504fa5ebcaf69539422fcd38bf157d1.camel@coelho.fi>
On Mon, 30 Jan 2023, Luca Coelho wrote:
> On Mon, 2023-01-30 at 09:37 +0100, Julia Lawall wrote:
> > > Sorry, false alarm. I was running spatch by itself on an inner
> > > directory (.../i915/display), but when I used find, I was using
> > > .../i915, so there was one more match happening there.
> > >
> > > So, it seems that the latest head _does_ work fine! And I'm gettign
> > > all
> > > the matches and changes that I expect. Thanks!
> >
> > Great news :)
>
> Maybe I celebrated a bit too early. There is still one instance that
> is not matching...
Probably it's a parse error.
Try putting the following in your semantic patch, egin the metavariable
list of macros_noargs:
iterator name with_intel_display_power_if_enabled;
If that is still not sufficient, try running
spatch --parse-c file.c
for the file of interest and see if it says BAD or bad on the lines of the
function that you expect should be matched.
julia
>
> I currently have these rules:
>
> @macros_noargs@
> identifier m;
> expression e =~ "dev_priv";
> @@
> #define m <+...e...+>
>
> @nested_macros@
> identifier macros_noargs.m;
> identifier nm;
> identifier list il;
> @@
> #define nm(il) <+...m...+>
>
> @@
> identifier nested_macros.nm;
> identifier dev_priv, f;
> expression list el;
> @@
> f(...) {
> ...
> struct drm_i915_private *dev_priv = ...;
>
> <+...
> nm(
> + dev_priv,
> el)
> ...+>
> }
>
> @@
> identifier nested_macros.nm;
> identifier dev_priv, f;
> expression list el;
> @@
> f(..., struct drm_i915_private *dev_priv, ...) {
> <+...
> nm(
> + dev_priv,
> el)
> ...+>
> }
>
> And then we have this function in
> drivers/gpu/drm/i915/display/intel_display.c:
>
> void vlv_wait_port_ready(struct drm_i915_private *dev_priv,
> struct intel_digital_port *dig_port,
> unsigned int expected_mask)
> {
> [...]
> switch (dig_port->base.port) {
> default:
> MISSING_CASE(dig_port->base.port);
> fallthrough;
> case PORT_B:
> port_mask = DPLL_PORTB_READY_MASK;
> dpll_reg = DPLL(0);
> break;
> case PORT_C:
> port_mask = DPLL_PORTC_READY_MASK;
> dpll_reg = DPLL(0);
> expected_mask <<= 4;
> break;
> [...]
> }
>
> The DPLL macro is defined like this (in
> drivers/gpu/drm/i915/display/i915_reg.h):
>
> #define _DPLL_A (DISPLAY_MMIO_BASE(dev_priv) + 0x6014)
> #define _DPLL_B (DISPLAY_MMIO_BASE(dev_priv) + 0x6018)
> #define _CHV_DPLL_C (DISPLAY_MMIO_BASE(dev_priv) + 0x6030)
> #define DPLL(pipe) _MMIO_PIPE3((pipe), _DPLL_A, _DPLL_B, _CHV_DPLL_C)
>
>
> So it should match like the other instances, but it doesn't. I copied
> the macro definition and the function to stand-alone files (i.e.
> without the rest of the code) and it matches, but in the real code,
> running cocci like this, it doesn't:
>
> ~/public/coccinelle/spatch.opt --sp-file ~/dev_priv_i915.spatch --all-includes intel_display.c
>
> I noticed some parsing errors when using --debug (output attached), so
> maybe there's some parsing issues with the real file that prevents the
> rule from applying?
>
> Any clues?
>
> --
> Cheers,
> Luca.
>
next prev parent reply other threads:[~2023-01-30 8:56 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-27 17:07 [cocci] Nested macros Luca Coelho
2023-01-27 18:34 ` [cocci] Checking selected macro calls with SmPL Markus Elfring
2023-01-27 20:52 ` [cocci] Nested macros Julia Lawall
2023-01-27 22:00 ` Luca Coelho
2023-01-28 9:19 ` Julia Lawall
2023-01-28 9:25 ` Luca Coelho
2023-01-28 9:46 ` [cocci] Searching for special function implementations with SmPL Markus Elfring
2023-01-28 9:49 ` Julia Lawall
2023-01-28 10:03 ` Luca Coelho
2023-01-28 13:33 ` Julia Lawall
2023-01-29 16:39 ` Luca Coelho
2023-01-29 17:28 ` Julia Lawall
2023-01-29 17:55 ` Luca Coelho
2023-01-29 19:15 ` Luca Coelho
2023-01-29 20:09 ` Julia Lawall
2023-01-30 6:32 ` Luca Coelho
2023-01-30 8:37 ` Julia Lawall
2023-01-30 8:50 ` Luca Coelho
2023-01-30 8:56 ` Julia Lawall [this message]
2023-01-30 9:05 ` Luca Coelho
2023-01-30 9:34 ` Markus Elfring
2023-01-30 9:41 ` Luca Coelho
2023-01-30 9:50 ` Markus Elfring
2023-01-30 9:52 ` Luca Coelho
2023-01-30 9:55 ` Julia Lawall
2023-01-30 10:07 ` Markus Elfring
2023-01-30 10:47 ` Julia Lawall
2023-01-30 10:59 ` Luca Coelho
2023-01-30 11:25 ` Markus Elfring
2023-01-31 15:57 ` Luca Coelho
2023-01-31 15:59 ` Luca Coelho
2023-01-31 16:08 ` Julia Lawall
2023-01-31 16:10 ` Luca Coelho
2023-01-31 16:20 ` Julia Lawall
2023-01-29 18:01 ` [cocci] Adding a parameter for special macro calls " Markus Elfring
2023-01-29 19:11 ` Luca Coelho
2023-01-28 13:43 ` [cocci] Searching for special function implementations " Markus Elfring
2023-01-29 16:41 ` Luca Coelho
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2fecadea-70f4-d4c0-d280-8776e5e12cb1@inria.fr \
--to=julia.lawall@inria.fr \
--cc=Markus.Elfring@web.de \
--cc=cocci@inria.fr \
--cc=luca@coelho.fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).