Will be speaking about KDevelop at LinuxCon Japan 2012

[Milian Wolff]

On Thursday 26 April 2012 15:33:44 Alexandre Courbot wrote:
> > Ah I thought you are talking about function pointers in general, which
> > afaik are not properly parsed/interpreted by our cpp lang code yet.
> 
> The parser does not raise any error, but the DUchain seems messed up
> indeed (e.g. pointing at a function pointer declared as a member of a
> struct will reference the struct).

Jup, reading your stuff below I think this is an essential part that needs to 
be fixed beforehand (otherwise, how to find out whether something is a 
function pointer?).

> >> Basically I need to
> >> detect where function pointers declarations are receiving a value,
> >> check if that value is constant, and record it somewhere to display it
> >> in the popup window.
> > 
> > This sounds... "special" - could you explain (maybe with some short code
> > examples) of what you actually want to know where? Generally I doubt this
> > kind of information is tracked by us yet.
> 
> It is a way to support "virtual functions" in C, which the kernel
> extensively uses to implement its abstractions. For instance, power
> management for a device is implemented through a struct that acts as a
> virtual function table:
> 
> struct dev_pm_ops {
> 	int (*suspend)(struct device *dev);
> 	int (*resume)(struct device *dev);
> }
> 
> A device driver can then include a pointer to this struct:
> 
> struct device_driver {
> 	const struct dev_pm_ops *pm;
> }
> 
> That way, device-independant code can call the device-specific suspend
> method like this:
> 
> 	driver->pm->suspend(device);
> 
> Which is equivalent to having a "driver" class with "suspend" and
> "resume" virtual functions. And just as KDevelop is capable is
> tracking overloaded virtual functions, I'd like to support the same
> for these function pointers. That is, as the parser notices a
> statement like that:
> 
> 	driver->pm->suspend = &foo_suspend;
> 
> or
> 
> struct device_driver bar_driver = {
> 	.pm = {
> 		.suspend = &bar_suspend,
> 	},
> };

Ah thanks :) I heard of such things, mostly from people who wondered whether 
the kernel people would rewrite some parts with C++ once Linus goes away and 
with him the NIH syndrome when it comes to such C++-mimicking :P Offtopic of 
course!

> I'd like to be able to present references to foo_suspend and
> bar_suspend every time the user points a call to the suspend member of
> dev_pm_ops.

OK, I see how this can be very useful. But big problem is how you want to 
track this... E.g.:

struct iface {
  funcPtr p;
}

struct b {
  iface i;
}

struct c {
  iface i;
}

Here, both b::i and c::i have the same type. But once you assign different 
*values* to b::i::p and c::i::p these should be shown differently... How? 
You'd need to store that information somewhere, essentially breaking the 
invariant that b::i has the same type as c::i.

One could try to assign a custom StructureType to declarations using a struct 
that contains function pointers and somehow introduce a mapping there... 
Question again is: What if one assigns different functions to the function 
pointer? I.e.: it shouldn't be a 1to1 mapping...


> That would be a real game-changer for kernel development. The kernel
> is *thousands* of drivers or architecture-specific functions used the
> same way, but most of the time only a few (and often only one) are
> used in a given configuration. Since kdev-kernel tunes the parser to
> only work on what is needed for the user's kernel configuration, it is
> only parsing the assignments that may be made at runtime. I can't
> stress enough how many hours are spent looking for where the hell
> could this stupid function pointer point to. With such a feature,
> navigating the kernel would be as easy as navigating C++ code with
> virtual functions.
> 
> I don't see why this would not be possible, but it requires some work
> - starting with proper function pointer support. Do you think I can
> realisticly get that done within a month?

This is certainly possible, but far from trivial (see above). Personally, with 
typical time constraints I'd definitely think this needs more than a month but 
if one would work full time on it it... Maybe it could be done...

> Unrelated, but it also appears more and more that I should also
> separate the C-specific behavior from the C++ parser (i.e. "class" or
> "virtual" are valid identifiers in C). If this freaks some people out,
> I could stick that to the yet-to-be "C specific" part of the parser
> (alongside with the designated initializers which are not valid in
> C++).

Yes this should be properly separated to not complicate our c++ parser. And 
you still need to find a way to define whether a file is c or c++ (esp. for .h 
files). Afaik that also was mentioned in the merge request for the designated 
initializers.

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120426/a2ede390/attachment.sig>