[Cocci] how to debug missing match?

Julia Lawall julia.lawall at lip6.fr
Sun Dec 21 11:55:56 CET 2014



On Sun, 21 Dec 2014, Wolfram Sang wrote:

> On Sun, Dec 21, 2014 at 11:39:14AM +0100, Julia Lawall wrote:
> > On Sun, 21 Dec 2014, Wolfram Sang wrote:
> > 
> > > 
> > > > does not result in anything although three drivers should match IMO with
> > > > the same pattern as the pmu driver above. Both use
> > > > platform_driver_register() and both have the .owner field set.
> > > > 
> > > > drivers/macintosh/windfarm_pm112.c
> > > > drivers/macintosh/windfarm_pm72.c
> > > > drivers/macintosh/windfarm_rm31.c
> > > > 
> > > > How can I debug why the match does not occur?
> > > 
> > > So, I found "--verbose-parsing" to be helpful which gives me:
> > > 
> > > parse error 
> > >  = File "drivers/macintosh/windfarm_pm112.c", line 685, column 4, charpos = 17702
> > >     around = 'nr_cores', whole content = 		++nr_cores;
> > > 
> > > which basically means that it can't handle for_each_node_by_type()?
> > > 
> > > bad: 	for_each_node_by_type(cpu, "cpu")
> > > BAD:!!!!! 		++nr_cores;
> > > 
> > > But neither "--include include/linux/of.h" nor "--recursive-includes"
> > > does help the case for me?
> > 
> > It is not surprising that adding more includes doesn't help.  But I would 
> > have thought that for_each_node_by_type, as it begins with for, would be 
> > something that it would pick up on.  I will take a look.
> 
> How does coccinelle work with such constructs? I'd think that replacing
> that #define with the actual for()-construct is much more reliable than
> an assumption like "it starts with 'for' so it is probably...' :)

When you replace things with other things, then you can't transform them.  
So it tries to guess.  It is possible that the guess only happens when the 
body of the loop has {}...

julia


More information about the Cocci mailing list