Solved (open source) condition coverage tools for C99

N

newbie32

I'm trying to put together a solution that requires CD/DC statistics of some (ancient) C99 code. I've no money for commercial products and the solutions for open source seem to be pretty much "use CUnit with gcov and hope" with the odd "did you try clang" thrown in. Gcov does work for determining the basic block/branch coverage I need, got some scripts to gather what CD results I can, but it's not great (especially since the stats on the conditions aren't actually the T/F that's needed, just 'hit' or not). Rewriting by hand through clang sort of works but the docs aren't great and I constantly seem to find known issues during the rewrite phase. Does anyone know of anything, library/script/excerpt from the Necrotelicomnicon, that actually gets condition coverage and is open? Source or binary instrumentation doesn't really matter since the code does compile.

For those that'll ask, trying to port a code base for a friend's dad but it's such a mess that I need to kill anything that's not actually being used in either "The Test" that was made for it or in operation, and port from there; He's going to be using a PI with Raspbian as the dedicated analysis machine (not FreeBSD but it's a start and he got it running on his own). No requirements and it was written in the early 90s (think gcc 2.9x is listed as the "most recent version" in some comments and Borland Turbo C++ was the original compiler). It's a science suite so I've got the notes from him about what's supposed to be happening and the doxygen for building up a tree but the many gotos employed means that "spaghetti" doesn't really cover it. Knowing what's hit (gcov) is a help but I gotta find out and plug what's actually needed for the calculations (hence the condition coverage). I know the original authors plugged a lot of miscellany in there to get the 'right' results for "The Test" so I'd love to be able to fix things up so that way he's got the 9 digits of precision needed rather than the 5 that everything was massaged to (so it could fit in printf per the comments--yeah, that bad).

Asked here as it's not really related to FreeBSD but who knows, maybe someone could put together a better test framework for package/system use from the results :)
 
Unfortunately, no. The formula's are at least getting close enough to a right result set, barring precision, that rebuilding them would take more time than figuring out the fixes. Plus there's some ANS.1 decoding and no one seems to have the format specification. The codebase is large enough that just doing away with it really isn't the best option: There's about a dozen or so over 10k SLOC files and about twice as many over 5k SLOC that comprise the calculation package: The actual calculations--most of it, input processing from the binary logs--some of it--and the networking code that delivers everything to the ancient Ingres database that will still be in use--the rest of the big stuff. We're already going to leave out the GUI code, basically just whatever Borland had to emulate a read-only curses display, so that drops a bunch of garbage. After reviewing it, some of the calculations are padded with just random stuff but he can't be certain (not a coder) and I'm not the scientist (never claimed to be smart, just arrogant :) ). Running things through gcov and doxygen does give me a great headstart but I do need some finer details in order to get the "right" bits down and I have no issue having to one off a solution, even a moderately complex one. Parsing C is not a moderately complex task, especially for doing instrumentation, which would still be needed for proper testing (CD/DC being the constant aim for quality in academia).

Does anybody have any experience with Eclipse CDT for doing something like this? I've looked into it before but I honestly haven't used Java for anything serious in like 5 years. (I am using Eclipse to setup the project and such so it seems like an idea.)
 
Ugh, I do not envy you. Dragging ancient projects into the modern era is not fun. Especially scientific programs!

(Removed the rest since I missed the plot and don't want to confuse other members reading it ;))
 
Just to correct kpedersen: As I stated above, I am the coder, not the scientist :). The build/setup and moving it over to an Eclipse project was actually the first thing I did (as well as giving it a debug build), followed immediately by the doxygen breakdown and gcov reports as soon as it was building. Which leads me to asking the question to further narrow down my work items. I do this kinda stuff for my job, which is why I got asked to do it, and occasionally for giggles with small stuff. Normally with the big stuff, it's a work item and I have access to tools the bosses paid for plus all sorts of fun toys I've built over the years that rely on said tools for the the rest. This is definitely the biggest one I've done under the "giggle" header but it is ultimately for a bunch of broke academics so I don't mind putting in some time and elbow grease.

When I do a project, I prefer regular makfiles or scons over CMake since I had to learn Make lingo for two platforms, BSD vs Linux, and darn near every platform I use has Python 2.7 installed somewhere. As for simple editors, it's Geany or nano. Never could get Code::Blocks working the way I wanted it to though I do know a couple folks who use it fairly regularly without hitch.

As for CDT, it really is just a series of libraries that create a plugin for Eclipse. I use Eclipse exclusively for anything that needs to be packaged for delivery with home and work stuff since I can usually just export the whole project, settings and all, into a zip directly from the IDE as well as gain the benefits of mouse over info and refactoring. It is a pain to setup initially but no more so than configuring makefiles or CMakeLists so I've never really seen a downside to the approach.

Different strokes and all.

Back on point though: I went a little more into the CDT libraries and they actually managed to be less documented and elements being less obvious than even clang. Not sure if that counts as a talent. Parsing for end-user use, it does seem a treat and it is readily available to me. For anyone interested, this guy has a quickie intro on getting the AST using CDT, https://github.com/ricardojlrufino/eclipse-cdt-standalone-astparser. This appears to be the only intro available into the process, at least as I was able to find after enjoying some turkey day feasting.
 
Just because I was caught in the delightful New England Snow (Storm) and had the time to put this up. Here's the github for the tool I built to get the coverage resolved (and my cheap excuse to open an account): https://github.com/new32/east

It's as accurate as I need it to be, others may not find it anymore useful than gcov but whatever. I ultimately had to use libtooling/CLang for it so at worst, look it as a tutorial for that :)
 
You must log in or register to reply here.
Back
Top