Question

I followed Claus’s post to set up code coverage on Xcode 4.2 with LLVM 3.0. I’m able to see test coverage files, but they’re only for my unit test classes, not my actual project classes. I’ve tried setting Generate Test Coverage Files and Instrument Program Flow to Yes on my main target, but that didn’t help, as it failed with the following error:

fopen$UNIX2003 called from function llvm_gcda_start_file

To clarify, I don’t think that’s even the right approach – I just tried it to see if it would generate code coverage on my project classes.

At this point, I’d be happy to try anything that gets code coverage working on my app. Any suggestions?

Answer 1

You are expecting linker problem, profile_rt library uses fopen$UNIX2003 and fwrite$UNIX2003 functions instead of fopen and fwrite.

All you need is to add the following .c file to your project:

#include <stdio.h>

FILE *fopen$UNIX2003( const char *filename, const char *mode )
{
    return fopen(filename, mode);
}

size_t fwrite$UNIX2003( const void *a, size_t b, size_t c, FILE *d )
{
    return fwrite(a, b, c, d);
}

This code just remaps the missing functions to standard ones.

Note on $UNIX2003 suffix:

I’ve found an Apple document saying:

The UNIX™ conformance variants use the $UNIX2003 suffix.

Important: The work for UNIX™ conformance started in Mac OS 10.4, but was not completed until 10.5. Thus, in the 10.4 versions of libSystem.dylib, many of the conforming variant symbols (with the $UNIX2003 suffix) exist. The list is not complete, and the conforming behavior of the variant symbols may not be complete, so they should be avoided.

Because the 64-bit environment has no legacy to maintain, it was created to be UNIX™ conforming from the start, without the use of the $UNIX2003 suffix. So, for example, _fputs$UNIX2003 in 32-bit and _fputs in 64-bit will have the same conforming behavior.

So I expect libprofile_rt to be linked against 10.4 SDK.