[llvm-dev] Using source-based code coverage on baremetal

Jonathan Roelofs via llvm-dev llvm-dev at lists.llvm.org
Wed Sep 6 14:26:43 PDT 2017

On 9/5/17 7:55 PM, Friedman, Eli via llvm-dev wrote:

> Areas that required LLVM changes:
> 1. The copy of libclangrt_profile.a for the target.  Given that we 
> already were using builtins from compiler-rt, the primary changes 
> required are enabling the profile library and excluding a bunch of files 
> from the build (since baremetal doesn't have a filesystem, system calls, 
> etc.).  I'll look into posting patches when I have time, but it might 
> take me a little while for me to figure out how to cleanly modify the 
> build, and verify everything actually works on trunk.  It looks like 
> there's a CMake variable COMPILER_RT_BAREMETAL_BUILD which is supposed 
> to be turned on for this sort of environment?

Yes, that's exactly what that variable is for.

See also: clang/cmake/caches/BaremetalARM.cmake. I haven't taught this 
how to do the rest of the runtime bits (unwinder/libcxxabi/libcxx), but 
plan to at some point.

> 2. Changing the compiler and compiler-rt to use __start and __end 
> symbols to find the sections, rather than .init code.  This isn't 
> strictly necessary, but our linker supports __start and __end, and this 
> was easier than changing the baremetal image to handle a .init section. 
> See needsRuntimeRegistrationOfSectionRange in 
> lib/Transforms/Instrumentation/InstrProfiling.cpp; we currently only 
> whitelist a few platforms.  Not sure what would be appropriate here; 
> maybe we could assume any *-none-* triple supports __start and __end 
> symbols?  Or maybe control it with a flag somehow? Or something else I'm 
> not thinking of?

A flag for this sounds great.


Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded / Siemens

More information about the llvm-dev mailing list