On Sun, Jul 3, 2011 at 10:34 PM, Reid Kleckner <reid.kleckner at gmail.com> wrote:> An easier way would be to use a coverage tool like gcov to see what's > actually *used* when the app is run normally. Then you can ask the > question, what percentage of all lines of code are dead?We need something that can do this using static analysis... Otherwise we can just use Eclipse and search for reference as a first approximation and try a rebuild. Tedious process. gcov is out of question we'd have to execute the entire program, which is a non-starter. That said, it would be interesting to add gcov to the testsuite to get a measure of how many percent of the application we're exercising....> A static analysis will not be able to see through things like virtual > method calls.Not even in theory? -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/
On Mon, Jul 4, 2011 at 1:42 AM, Øyvind Harboe <oyvind.harboe at zylin.com> wrote:> On Sun, Jul 3, 2011 at 10:34 PM, Reid Kleckner <reid.kleckner at gmail.com> wrote: >> An easier way would be to use a coverage tool like gcov to see what's >> actually *used* when the app is run normally. Then you can ask the >> question, what percentage of all lines of code are dead? > > We need something that can do this using static analysis... Otherwise > we can just use Eclipse and search for reference as a first approximation > and try a rebuild. Tedious process. gcov is out of question we'd have > to execute the entire program, which is a non-starter. > > That said, it would be interesting to add gcov to the testsuite to get a measure > of how many percent of the application we're exercising.... > >> A static analysis will not be able to see through things like virtual >> method calls. > > Not even in theory?It's provably undecidable to do so in general, because aliasing is statically undecidable. http://academic.research.microsoft.com/Publication/857191/the-undecidability-of-aliasing (and the more complicated paper it cites by Landi). This is not to say it's not possible to resolve any of them sometimes, it means in general you will not be able to. There are a number of static analysis to do things like class hierarchy resolution which may be able to prove which classes some virtual calls will call. It does generally require you assert to the compiler that you will not change the class hierarchy later (through dynamic loading/etc), or else you need to redo the analysis at that point. It is also meant for compiler optimization, not code coverage. It's purpose is to get good enough results fast, so that even if it can't resolve a call, it may let you eliminate other possibilities and make guarded direct calls. Basically, what you are trying to do (statically decide code coverage) is statically impossible, and one can probably prove you can't even probabilistically estimate it to within some reasonable factor.
I think what you're looking for is something like Doxygen or CodeViz that can generate (imperfect) call graphs for you. It sounds like you just need a rough list of functions that might be unused to start with. -Scott On Sun, Jul 3, 2011 at 11:04 PM, Daniel Berlin <dberlin at dberlin.org> wrote:> On Mon, Jul 4, 2011 at 1:42 AM, Øyvind Harboe <oyvind.harboe at zylin.com> wrote: >> On Sun, Jul 3, 2011 at 10:34 PM, Reid Kleckner <reid.kleckner at gmail.com> wrote: >>> An easier way would be to use a coverage tool like gcov to see what's >>> actually *used* when the app is run normally. Then you can ask the >>> question, what percentage of all lines of code are dead? >> >> We need something that can do this using static analysis... Otherwise >> we can just use Eclipse and search for reference as a first approximation >> and try a rebuild. Tedious process. gcov is out of question we'd have >> to execute the entire program, which is a non-starter. >> >> That said, it would be interesting to add gcov to the testsuite to get a measure >> of how many percent of the application we're exercising.... >> >>> A static analysis will not be able to see through things like virtual >>> method calls. >> >> Not even in theory? > > It's provably undecidable to do so in general, because aliasing is > statically undecidable. > http://academic.research.microsoft.com/Publication/857191/the-undecidability-of-aliasing > (and the more complicated paper it cites by Landi). > > This is not to say it's not possible to resolve any of them sometimes, > it means in general you will not be able to. > There are a number of static analysis to do things like class > hierarchy resolution which may be able to prove which classes some > virtual calls will call. > It does generally require you assert to the compiler that you will not > change the class hierarchy later (through dynamic loading/etc), or > else you need to redo the analysis at that point. It is also meant > for compiler optimization, not code coverage. It's purpose is to get > good enough results fast, so that even if it can't resolve a call, it > may let you eliminate other possibilities and make guarded direct > calls. > > Basically, what you are trying to do (statically decide code coverage) > is statically impossible, and one can probably prove you can't even > probabilistically estimate it to within some reasonable factor. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >