This patch builds on LLVM r279776.
In this patch I've done some cleanup and abstracted three common steps runtime components have in their CMakeLists files, and added a fourth.
The three steps I abstract are:
(1) Add a top-level target (i.e asan, msan, ...)
(2) Set the target properties for sorting files in IDE generators
(3) Make the compiler-rt target depend on the top-level target
The new step is to check if a command named "runtime_register_component" is defined, and to call it with the component name.
The runtime_register_component command is defined in llvm/runtimes/CMakeLists.txt, and presently just adds the component to a list of sub-components, which later gets used to generate target mappings.
With this patch a new workflow for runtimes builds is supported. The new workflow when building runtimes from the LLVM runtimes directory is:
> cmake [...]
> ninja runtimes-configure
> ninja asan
The "runtimes-configure" target builds all the dependencies for configuring the runtimes projects, and runs CMake on the runtimes projects. Running the runtimes CMake generates a list of targets to bind into the top-level CMake so subsequent build invocations will have access to some of Compiler-RT's targets through the top-level build.
Note: This patch does exclude some top-level targets from compiler-rt libraries because they either don't install files (sanitizer_common), or don't have a cooresponding `check` target (stats).
llvm-svn: 279863
The API is intended to be used by user to do fine
grained (per-region) control of profile dumping.
Differential Revision: http://reviews.llvm.org/D23106
llvm-svn: 278092
Summary:
This patch is a refactoring of the way cmake 'targets' are grouped.
It won't affect non-UI cmake-generators.
Clang/LLVM are using a structured way to group targets which ease
navigation through Visual Studio UI. The Compiler-RT projects
differ from the way Clang/LLVM are grouping targets.
This patch doesn't contain behavior changes.
Reviewers: kubabrecka, rnk
Subscribers: wang0109, llvm-commits, kubabrecka, chrisha
Differential Revision: http://reviews.llvm.org/D21952
llvm-svn: 275111
Here's the warnings and how they were fixed:
- InstrProfilingUtil.c(110): warning C4013: '_open_osfhandle' undefined; assuming extern returning int
Include io.h to get the prototype.
- warning C4005: 'FILE_MAP_EXECUTE': macro redefinition
Stop trying to support pre-XP versions of Windows, don't attempt to
define this macro.
- InstrProfilingWriter.c(271): warning C4221: nonstandard extension used: 'Data': cannot be initialized using address of automatic variable 'Header'
- InstrProfilingWriter.c(275): warning C4221: nonstandard extension used: 'Data': cannot be initialized using address of automatic variable 'Zeroes'
Turn this warning off. This is definitely legal in C++, all compilers
accept it, and I only have room for half of one language standard in my
brain.
- InstrProfilingValue.c(320): warning C4113: 'uint32_t (__cdecl *)()' differs in parameter lists from 'uint32_t (__cdecl *)(void)'
Fix this with an explicit (void) in the prototype.
- InstrProfilingMerge.c.obj : warning LNK4006: _VPMergeHook already defined in InstrProfilingMergeFile.c.obj; second definition ignored
Last remaining warning. This is from linking a selectany definition with
a strong definition. We need to sort out weak symbols in compiler-rt in
general, though.
llvm-svn: 273026
- lprofCurFilename was intended to have external visibility. This is
pending further discussion.
- The raw version number doesn't need to be hidden: hiding it may make
it easier to accidentally combine FE/IR profiles.
See the mailing list discussion on r272081.
llvm-svn: 272089
There are still a few external symbols visible from InstrProfData.inc.
The plan for dealing with those isn't as straightforward, so I'll try it
in a separate commit.
llvm-svn: 272081
(Part-1 merging API is in profile runtime)
This patch implements a portable file opening API
with exclusive access for the process. In-process
profile merge requires profile file update to be
atomic/fully sychronized.
llvm-svn: 271864
The max warning check was masking the "return 0" codepath.
See the thread "Warnings and compile-time failure on 458.sjeng" for more
info.
llvm-svn: 270762
After r270617 I am getting an error when building:
projects/compiler-rt/lib/profile/InstrProfilingFile.c:33:36:
error: missing field 'PidChars' initializer
[-Werror,-Wmissing-field-initializers]
lprofFilename lprofCurFilename = {0};
^
Fix the aggregate initializer.
llvm-svn: 270697
Saleem Abdulrasool