This adds a copy of the demangler in libcxxabi.
The code also has no dependencies on anything else in LLVM. To enforce
that I added it as another library. That way a BUILD_SHARED_LIBS will
fail if anyone adds an use of StringRef for example.
The no llvm dependency combined with the fact that this has to build
on linux, OS X and Windows required a few changes to the code. In
particular:
No constexpr.
No alignas
On OS X at least this library has only one global symbol:
__ZN4llvm16itanium_demangleEPKcPcPmPi
My current plan is:
Commit something like this
Change lld to use it
Change lldb to use it as the fallback
Add a few #ifdefs so that exactly the same file can be used in
libcxxabi to export abi::__cxa_demangle.
Once the fast demangler in lldb can handle any names this
implementation can be replaced with it and we will have the one true
demangler.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280732 91177308-0d34-0410-b5e6-96231b3b80d8
sufficient in some cases; increase to 64KB, which should be enough for anyone :)
Patch by github.com/bryant!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@279599 91177308-0d34-0410-b5e6-96231b3b80d8
If the result of the find is only used to compare against end(), just
use is_contained instead.
No functionality change is intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278469 91177308-0d34-0410-b5e6-96231b3b80d8
This makes sure that space is actually available. With this change
running lld on a full file system causes it to exit with
failed to open foo: No space left on device
instead of crashing with a sigbus.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276017 91177308-0d34-0410-b5e6-96231b3b80d8
looking for it along $PATH. This allows installs of LLVM tools outside of
$PATH to find the symbolizer and produce pretty backtraces if they crash.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272232 91177308-0d34-0410-b5e6-96231b3b80d8
the C standard library implementation in use.
This works around a glibc bug in the backtrace() function where it fails to
produce a backtrace on x86_64 if libgcc / libunwind is statically linked.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270276 91177308-0d34-0410-b5e6-96231b3b80d8
- glibc is dynamically linked, and
- libgcc_s is unavailable (for instance, another library is being used to
provide the compiler runtime or libgcc is statically linked), and
- the target is x86_64.
If we run backtrace() and it fails to find any stack frames, try using
_Unwind_Backtrace instead if available.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269992 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r269577.
Broke NetBSD, waiting for Kamil to investigate
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269584 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r221331 and reinstate r220932 as discussed in D19271.
Original commit message was:
This patch adds an llvm_call_once which is a wrapper around
std::call_once on platforms where it is available and devoid
of bugs. The patch also migrates the ManagedStatic mutex to
be allocated using llvm_call_once.
These changes are philosophically equivalent to the changes
added in r219638, which were reverted due to a hang on Win32
which was the result of a bug in the Windows implementation
of std::call_once.
Differential Revision: http://reviews.llvm.org/D5922
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269577 91177308-0d34-0410-b5e6-96231b3b80d8
In the current implementation compiler only prints stack trace
to console after crash. This patch adds saving of minidump
files which contain a useful subset of the information for
further debugging.
Differential Revision: http://reviews.llvm.org/D18216
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268519 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r265074 and r265068.
Breaks windows build
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265080 91177308-0d34-0410-b5e6-96231b3b80d8
Breaks windows bot.
This reverts commit r265050.
This reverts commit r265055.
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265062 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r264387.
Bots are broken in various ways, I need to take one commit at a time...
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264390 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Hi Rafael,
Would you be able to review this patch, please?
(Clang part of the patch is D15832).
When clang runs an external tool, e.g. a linker, it may create a command line that exceeds the length limit.
Clang uses the llvm::sys::argumentsFitWithinSystemLimits function to check if command line length fits the OS
limitation. There are two problems in this function that may cause exceeding of the limit:
1. It ignores the length of the program path in its calculations. On the other hand, clang adds the program
path to the command line when it runs the program.
2. It assumes no space character is inserted after the last argument, which is not true for Windows. The flattenArgs function adds the trailing space for *each* argument. The result of this is that the terminating NULL character is not counted and may be placed beyond the length limit if the command line is exactly 32768 characters long. The WinAPI's CreateProcess does not find the NULL character and fails.
Reviewers: rafael, ygao, probinson
Subscribers: asl, llvm-commits
Differential Revision: http://reviews.llvm.org/D15831
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256866 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: On Windows, the allocation granularity can be significantly
larger than a page (64K), so with many small objects, just clearing
the FreeMem list rapidly leaks quite a bit of virtual memory space
(if not rss). Fix that by only removing those parts of the FreeMem
blocks that overlap pages for which we are applying memory permissions,
rather than dropping the FreeMem blocks entirely.
Reviewers: lhames
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15202
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255760 91177308-0d34-0410-b5e6-96231b3b80d8
I am seeing disappointing clang performance on a large PowerPC64
Linux box. GetRandomNumberSeed() does a buffered read from
/dev/urandom to seed its PRNG. As a result we read an entire page
even though we only need 4 bytes.
With every clang task reading a page worth of /dev/urandom we
end up spending a large amount of time stuck on kernel spinlock.
Patch by Anton Blanchard!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255386 91177308-0d34-0410-b5e6-96231b3b80d8
setExecutable() should do everything that's needed to make the memory
executable on host, i.e. unconditionally set permissions + invalidate
instruction cache. llvm-rtdyld will be updated in my next commit.
Discusseed with: Lang Hames (as part of D13631).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@253341 91177308-0d34-0410-b5e6-96231b3b80d8
