Re: [Cocci] how to debug missing match?

2014-12-21 Thread Julia Lawall
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.

julia
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci


Re: [Cocci] how to debug missing match?

2014-12-21 Thread Wolfram Sang
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...' :)



signature.asc
Description: Digital signature
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci


Re: [Cocci] how to debug missing match?

2014-12-21 Thread Julia Lawall


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
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci