[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
--
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded / Siemens
More information about the llvm-dev
mailing list