Unused methods dipped from 1411 to 1008 as most unused chart2 methods are removed, and a big pile of sc ones. leaving sd as the new leader module.
This entry was posted
on Thursday, October 9th, 2008 at 9:02 am and is filed under General.
You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
Hey Caolan,
A reader on my blog pointed me to yours. Looks like we have similar interests regarding code analysis.
I’ve developed a couple of tools that might be of interest to you, gcc-plugin analyzer stuff and C++ rewriting stuff based on Elsa. Perhaps, you would be interested in adopting some of these for your work and helping me demonstrate that the tools are generally useful.
Also, I’m not so sure about it being possible to detect dead code precisely using GCC(or any output of GCC). In mozilla we have code that takes an address of a virtual method and casts it to another virtual method pointer type…for which gcc produces a data structure that only contains an offset relative to vptr(no mention of the method). I can’t see this being solved without assuming that every virtual method at that particular offset is used OR extending GCC to leave more metadata. Then again, this pattern may not be present in openoffice
I also have my tool catch dead member uses too, even if it’s behind in being precise about overloads and virtual methods
Callcatcher is a “terrible hack”, it scrapes the intermediate assembly and explicitly marks *all* (exported) virtual methods as potentially used. So we’re talking about non-virtual methods in these lists of used cruft.
Though I had thought about seeing if a particular vtable slot could never be used to detect whole vertical unused slices of a virtual method. Which is more what you’re talking about here, but then we’d fall into the same hole for UNO as you describe for moz, so we’d have to differentiate (though this would be probably doable) between virtual methods that implement a UNO api which will be called through sneaky uno-bridge trickery by calling into a given slot at an offset from the vtable and “vanilla” ones whose vtable usages would be visible to gcc.
Any thoughts along those lines I punted until there were no more low-hanging methods left to remove