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
Tim Northover