Currently we register instrumentation data at runtime to determine the
bounds of the sections where the data lives. Soon we'll implement
platform-specific linker magic to determine this at link time.
Move this logic to a separate file, so that our build system can choose
the correct platform-specific code.
No functionality change intended.
<rdar://problem/15943240>
llvm-svn: 204299
Since these are primarily useful for deeply embedded targets where code size is
very important, they are each in a separate file making use of infrastructure
in sync-ops.h. This allows a linker to include just the functions that are
actually used.
rdar://problem/14736665
llvm-svn: 202812
When actually compiling we use clang for the final .dylib creation stage, so we
should ask it what linker it'll use when detecting support for our
architectures.
llvm-svn: 201845
When the locale of a shell is set other than English locales or the C locale,
The word 'Target' may be translated. Thus, with e.g. ja_JP locale, compiler-rt
couldn't be built properly. Forcing LANG=C fixes the problem.
Patch by Ogino Masanori.
llvm-svn: 201506
Clang now uses the *-apple-macho triples for embedded targets using MachO. The
environment makes less pretences to be running an actual Mach kernel with all
the support that would imply, so a few changes are needed to the build scripts:
+ The Apple way of detecting endianness applies in all cases so drop the
__MACH__ test.
+ A quick rename since "darwin_embedded" no longer makes any sense. If there's
no Mach going on, there's certainly no Darwin.
+ Change how we test for support for a platform. The functions we build don't
need any SDK support (stdio.h, ...) so we don't need to check for it.
llvm-svn: 199731
This is fairly minimal support for instrumentation based PGO. The data
format is inefficient, and the output file name is hardcoded to
pgo-data.
llvm-svn: 198638
We need to filter out architectures that the compiler hasn't been built to
target (most likely the ARM ones) before attemptint to build a version of
libcompiler_rt.
This can result in a completely empty library (e.g. soft-float doesn't have any
x86 variants), in which case we shouldn't even try the build
llvm-svn: 197028
This should build a separate set of embedded runtime libraries, supporting the
option product:
{PIC, static} x { Hard-float, soft-float }
The emphasis is on ARM platforms (Cortex-M4F, Cortex-M3, Cortex-M0) but X86
variants are also built where possible.
rdar://problem/10817205
llvm-svn: 194873
DataFlowSanitizer is a generalised dynamic data flow analysis.
Unlike other Sanitizer tools, this tool is not designed to detect a
specific class of bugs on its own. Instead, it provides a generic
dynamic data flow analysis framework to be used by clients to help
detect application-specific issues within their own code.
Differential Revision: http://llvm-reviews.chandlerc.com/D967
llvm-svn: 187924
restriction from the GCDAProfile.c"
Bill added a much more effective way of coping with the use of errno and
other system interactions for Darwin for now by disabling it on that
platform. Building against the SDK stuff is more fundamental to the
darwin build process.
llvm-svn: 184929
darwin.
After talking with Jim Grosbach pretty extensively, he was OK with me
punting on this to the Apple folks.
We agreed that the correct fix is either to extend the fake SDK headers
in compiler-rt to support the rest of libc needed by GCDAProfiling.c or
to teach the make build to test for the existence of a suitable SDK on
the system prior to building it. Both of these require someone with
access to the SDK which I don't have, and the latter (my preferred
solution) requires understanding the strange compiler-rt make build
system. Punting to Dan Dunbar or one of the others who support this
stuff on ios to write the appropriate fix, and we can let the build bots
proceed in the mean time.
llvm-svn: 184816
runtime in the Makefile build system as well. Sorry for the temporary
fallout, it took me a while to find these bits.
Bill, I'm not at all confident of the change for Darwin and iOS, but as
discussed we're completely blocked on fixing this. Anyways, please
review and let me know if this will work for you guys. If necessary,
I can work with you to rig up an errno.h stub for Darwin, but I expect
that to be... moderately challenging.
llvm-svn: 184805
the build right from the start.
For now, it is only done with DEBUGMAKE is provided. That makes
things harder to debug during ports of compiler-rt on other systems.
llvm-svn: 184295
When building compiler-rt on Linux, the "which sw_vers" check fails and
writes an error message into the build log. Apparently on Solaris "which"
writes the error message to stdout, so that the current test won't even
work properly. As far as I know sw_vers always lives in /usr/bin, so just
check for it there instead of using "which".
llvm-svn: 180792
We now rely on the -mios-simulator-version-min option to identify the iOS
simulator target. I'm not sure if there's anything in compiler-rt where that
matters, but it's the right thing to do regardless.
llvm-svn: 180163
* libclang_rt-san-* is sanitizer_common, and is linked in only if no other
sanitizer runtime is present.
* libclang_rt-ubsan-* is the piece of the runtime which doesn't depend on
a C++ ABI library, and is always linked in.
* libclang_rt-ubsan_cxx-* is the piece of the runtime which depends on a
C++ ABI library, and is only linked in when linking a C++ binary.
The Darwin ubsan runtime is unchanged.
For more details, see Clang change r177605.
llvm-svn: 177606
library.
These headers are intended to be available to user code when built with
AddressSanitizer (or one of the other sanitizer's in the future) to
interface with the runtime library. As such, they form stable external
C interfaces, and the headers shouldn't be located within the
implementation.
I've pulled them out into what seem like fairly obvious locations and
names, but I'm wide open to further bikeshedding of these names and
locations.
I've updated the code and the build system to cope with the new
locations, both CMake and Makefile. Please let me know if this breaks
anyone's build.
The eventual goal is to install these headers along side the Clang
builtin headers when we build the ASan runtime and install it. My
current thinking is to locate them at:
<prefix>/lib/clang/X.Y/include/sanitizer/common_interface_defs.h
<prefix>/lib/clang/X.Y/include/sanitizer/asan_interface.h
<prefix>/lib/clang/X.Y/include/sanitizer/...
But maybe others have different suggestions?
Fixing the style of the #include between these headers at least unblocks
experimentation with installing them as they now should work when
installed in these locations.
llvm-svn: 162822
I'm not sure if this is the right fix, but this has been broken
for two weeks and pleas for review were ignored. It seems to do
the right thing.
llvm-svn: 158466
which will contain code shared between asan and tsan run-times.
Naming is hard. If you can suggest a better name for the directory -- speak up.
llvm-svn: 157611
the stub SDK to try and ensure we always pick up the right archs when they
should be able to be used.
- Also, warn when we drop an architecture.
This is a reapplication of r150232 that should stick now that we have the
integrated assembler on for ARM.
llvm-svn: 152057
the stub SDK to try and ensure we always pick up the right archs when they
should be able to be used.
- Also, warn when we drop an architecture.
llvm-svn: 150232
stub SDK.
- This allows us to build both the m32 and m64 variants without worrying about
whether or not the user has the headers for the alternate arch installed.
llvm-svn: 146132
sets of functions/objects into high level groups. Currently we have "builtins"
(the main compiler-rt code), "profile", and "asan".
- Use this to define CommonFunctions and ArchFunctions to only reference the
builtins functions.
llvm-svn: 145674
Duncan P. N. Exon Smith