The problem is due to the section name being explicitly mentioned in
the IR and differing between the two platforms.

llvm-svn: 187394

update testcase to make sure we generate debug info for walrus
by adding a non-trivial constructor and verify that we don't
emit an ODR signature for the type.

llvm-svn: 187393

sure the comments for each testcase are a bit easier to distinguish.

llvm-svn: 187392

odr hashes.

llvm-svn: 187391

The command line option in .drectve section may be quoted by double
quotes, and if that's the case we have to remove them.

llvm-svn: 187390

- newer gcc generates additional debuginfo for function exit (stack object desctruction) which was causing tests to fail
- work-around consists of not declaring any stack objects in main()

llvm-svn: 187389

This patch removes hacky mangle() function, which strips all decorations
uncondtitionally. LLD now interprets Import Name/Type field in the import
library properly as described in the Microsoft PE/COFF Spec.

llvm-svn: 187388

llvm-svn: 187387

Reviewers: rsmith

Reviewed By: rsmith

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D1183

llvm-svn: 187386

llvm-svn: 187385

llvm-svn: 187384

llvm-svn: 187383

llvm-svn: 187382

llvm-svn: 187381

llvm-svn: 187380

llvm-svn: 187379

This will let us use getUniqueID instead of st_dev directly on clang.

llvm-svn: 187378

LLDB requires that the inferior process be stopped before, and remain
stopped during, certain accesses to process state.

Previously this was achieved with a POSIX rwlock which had a write lock
taken for the duration that the process was running, and released when
the process was stopped.  Any access to process state was performed with
a read lock held.

However, POSIX requires that pthread_rwlock_unlock() be called from the
same thread as pthread_rwlock_wrlock(), and lldb needs to stop and start
the process from different threads.  Violating this constraint is
technically undefined behaviour, although as it happens Linux and Darwin
result in the unlock proceeding in this case.  FreeBSD follows POSIX
more strictly, and the unlock would fail, resulting in a hang later upon
the next attempt to take the lock.

All read lock consumers use ReadTryLock() and handle failure to obtain
the lock (typically by logging an error "process is running").  Thus,
instead of using the lock state itself to track the running state, this
change adds an explicit m_running flag.  ReadTryLock tests the flag, and
if the process is not running it returns with the read lock held.

WriteLock and WriteTryLock are renamed to SetRunning and TrySetRunning,
and (if successful) they set m_running with the lock held.  This way,
read consumers can determine if the process is running and act
appropriately, and write consumers are still held off from starting the
process if read consumers are active.

Note that with this change there are still some curious access patterns,
such as calling WriteUnlock / SetStopped twice in a row, and there's no
protection from multiple threads trying to simultaneously start the
process.  In practice this does not seem to be a problem, and was
exposing other undefined POSIX behaviour prior to this change.

llvm-svn: 187377

output rather than just part of it.

Also, remove the frighteningly ancient comment about not working with
the gcc-driver. (!!!)

llvm-svn: 187376

llvm-svn: 187375

corresponding 'operator new' was actually emitted as a function marked 'nobuiltin'.

llvm-svn: 187374

llvm-svn: 187373

This is so DFSan will be able to use it.

Differential Revision: http://llvm-reviews.chandlerc.com/D1206

llvm-svn: 187372

llvm-svn: 187371

llvm-svn: 187370

Debug mode for unordered_multiset.  The exercise spotted a few places I had missed on unordered_set, so I picked those up as well.

There are actually two debug modes:

   1.  -D_LIBCPP_DEBUG2 or -D_LIBCPP_DEBUG2=1
       This is a relatively expensive debug mode, but very thorough.  This is normally what you want to debug with, but may turn O(1) operations into O(N) operations.

   2.  -D_LIBCPP_DEBUG2=0
       This is "debug lite."  Only preconditions that can be checked with O(1) expense are checked.  For example range checking on an indexing operation.  But not iterator validity.

llvm-svn: 187369

Thanks Eric.

llvm-svn: 187368

llvm-svn: 187367

The quotes (from r187330) didn't really help here, the trick was to disable
the test on MSYS builds. This removes those quotes, changes back the comment
to explain why /? has to be quoted specifically, and moves the REQUIRES
line to the top of the file because that's important.

llvm-svn: 187366

Patch by Ethan Jackson.

llvm-svn: 187365

llvm-svn: 187364

llvm-svn: 187363

llvm-svn: 187362

in LLDB that load the canonical frame address rather than a location list.

- Handles the simple case where a CFA can be pulled from the current stack frame.
- Fixes more than one hundred failing tests with gcc 4.8!

TODO: Use UnwindPlan::GetRowForFunctionOffset if the DWARFExpression needs
to be evaluated in a context analogous to a virtual unwind (perhaps using RegisterContextLLDB).

- Also adds some comments to DWARFCallFrameInfo whenever I got confused.

llvm-svn: 187361

This change add a new option command line option -for-compilers that allows the
user to enable multiple transforms automatically.

Another difference is that now all transforms are enabled by default.

llvm-svn: 187360

On windows, c:foo is a valid file path, but stat fails on just "c:". This
causes a problem for clang since its file manager wants to cache data about
the parent directory.

There are refactorings to be done in here, but this gives clang the correct
behavior and testing first.

Patch by Yunzhong Gao!

llvm-svn: 187359

Add operator new[] to test.  Partial fix for valgrind warning in http://llvm.org/bugs/show_bug.cgi?id=16703.

llvm-svn: 187358

llvm-svn: 187357

32-bit symbols have "_" as global prefix, but when forming the name of
COMDAT sections this prefix is ignored. The current behavior assumes that
this prefix is always present which is not the case for 64-bit and names
are truncated.

llvm-svn: 187356

Win64 uses CharPtrBuiltinVaList instead of X86_64ABIBuiltinVaList like
other 64-bit targets.

llvm-svn: 187355