full proper list of dynamic symbols crashes old gold (see bug 16468).
the culprit is 'memcpy' function, if it's added to syms file, gold crashes
llvm-svn: 185078
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
(thanks!) by deferring the free of the filename until we finish writing
the coverage data to that file.
Bill, let me know if you'd prefer a different approach!
llvm-svn: 184895
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
through Bill's patch:
1) Correctly test the file descriptor after the sceond attempt at
creating the file.
2) Make the filename a global so that we can issue error messages from
other routines.
3) Check errno in several places and print it out so that errors are
easier to track down.
I don't really expect any of these to fix the current failures I'm
seeing, but I'm hopeful they'll at least let me debug them.
llvm-svn: 184799
We really need the C standard library to be available to implement the
profiling runtime library reasonably, and replicating everything in the
SDKs tree really isn't addressing any problems we have. Notably, all of
the sanitizer runtimes take the same approach, and this isn't a library
which could end up in a bootstrapping problem where the system headers
aren't even available.
This will hopefully prevent subsequent changes which start using various
other bits of C standard library to make things more debuggable.
llvm-svn: 184798
Bill Wendling