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
