llvm-svn: 242124

http://reviews.llvm.org/D11075

Patch by Martell Malone
Reviewed by Reid Kleckner

llvm-svn: 242123

Fixed line wrapping for the "long help" content in LLDB commands.  Content is now dynamically wrapped for the column width of the current terminal.  Lines that begin with whitespace will be indented identically on subsequent lines to maintain formatting.

Existing commands supplying this type of help content have been reworked to take advantage of the changes.  In addition to formatting changes, content was changes for accuracy and clarity purposes.
    
<rdar://problem/21269977>

llvm-svn: 242122

We will still default to ld until such a time lld become a 
stable release. lld supports arm NT under the machine name "thumb2pe".

http://reviews.llvm.org/D11088

Patch by Martell Malone
Reviewed by Reid Kleckner

llvm-svn: 242121

LLVM_EXTERNAL_*_SOURCE_DIR is reset as PATH with set(CACHE PATH).
Then the CACHE PATH variable, LLVM_EXTERNAL_*_SOURCE_DIR, is normalized as
${CMAKE_SOURCE_DIR}/${path_var} if ${path_var} is relative.

llvm-svn: 242120

that would not pass through empty ("unsupported packet") replies
correctly.

llvm-svn: 242119

llvm-svn: 242118

llvm-svn: 242117

llvm-svn: 242116

Thread local storage is not implemented for targeting cygwin.

llvm-svn: 242115

vm_kernel_page_size appears to not be defined on OSX Mavericks, so the
build fails.  This patch fixes the build by calculating the pagesize if
_VM_PAGE_SIZE_H_ is not defined.

llvm-svn: 242114

llvm-svn: 242113

This reverts commit r242006. The original issue in Clang was fixed in r242009,
so we can now safely use std::atomic_flag.

llvm-svn: 242112

llvm-svn: 242111

Entry name selection rule is already complicated on x64, but it's more
complicated on x86 because of the underscore name mangling scheme.

If one of _main, _main@<number> (a C function) or ?main@@... (a C++ function)
is defined, entry name is _mainCRTStartup. If _wmain, _wmain@<number or
?wmain@@... is defined, entry name is _wmainCRTStartup. And so on.

llvm-svn: 242110

llvm-svn: 242109

Accidental commit, needs review first.

This reverts commit r242107.

llvm-svn: 242108

- Factor out code to query and modify the sign bit of a floatingpoint
  value as an integer. This also works if none of the targets integer
  types is big enough to hold all bits of the floatingpoint value.

- Legalize FABS(x) as FCOPYSIGN(x, 0.0) if FCOPYSIGN is available,
  otherwise perform bit manipulation on the sign bit. The previous code
  used "x >u 0 ? x : -x" which is incorrect for x being -0.0! It also
  takes 34 instructions on ARM Cortex-M4. With this patch we only
  require 5:
    vldr d0, LCPI0_0
    vmov r2, r3, d0
    lsrs r2, r3, #31
    bfi r1, r2, #31, #1
    bx lr
  (This could be further improved if the compiler would recognize that
   r2, r3 is zero).

- Only lower FCOPYSIGN(x, y) = sign(x) ? -FABS(x) : FABS(x) if FABS is
  available otherwise perform bit manipulation on the sign bit.

- Perform the sign(x) test by masking out the sign bit and comparing
  with 0 rather than shifting the sign bit to the highest position and
  testing for "<s 0". For x86 copysignl (on 80bit values) this gets us:
    testl $32768, %eax
  rather than:
    shlq $48, %rax
    sets %al
    testb %al, %al

llvm-svn: 242107

This makes the changes in an upcoming patch visible.

llvm-svn: 242106

[modules] When diagnosing errors in module map files found by 'extern module' declarations, show how we got to that module map file.

llvm-svn: 242105

Summary:
The capability was lost with D10429 where the personality function was set at function level rather than landing pad level. Now there is no way to get/set the personality function from the C API. That is a problem.

Note that the whole thing could be avoided by improving the C API testing, as started by D10725

Reviewers: chandlerc, bogner, majnemer, andrew.w.kaylor, rafael, rnk, axw

Subscribers: rafael, llvm-commits

Differential Revision: http://reviews.llvm.org/D10946

llvm-svn: 242104

llvm-svn: 242103

add_llvm_external_project puts LLVM_EXTERNAL_${nameUPPER}_SOURCE_DIR into the cache even if it is just the in-tree default path. This causes all sorts of oddness, and makes it so that I can't change the behavior of this variable.

This patch never puts LLVM_EXTERNAL_${nameUPPER}_SOURCE_DIR into the cache. It will only end up in the cache if it is specified on the command line, which is the correct behavior.

There is also a temporary change to remove non-default values from the cache if they are already present. This should have the impact of cleaning out unncecissary values from the caches on the buildbots and people's local build directories. This part of the change is marked with a TODO and can be removed in a few days.

llvm-svn: 242102

Summary:
- Consolidate Unix signals selection in UnixSignals.
- Make Unix signals available from platform.
- Add jSignalsInfo packet to retrieve Unix signals from remote platform.
- Get a copy of the platform signal for each remote process.
- Update SB API for signals.
- Update signal utility in test suite.

Reviewers: ovyalov, clayborg

Subscribers: chaoren, jingham, labath, emaste, tberghammer, lldb-commits

Differential Revision: http://reviews.llvm.org/D11094

llvm-svn: 242101

llvm-svn: 242100

which is actually the variable backing up the llvm -time-passes command
line argument.
llvm::TimePassesIsEnabled is actually being initialized in CodeGenAction.

llvm-svn: 242099

llvm-svn: 242098

Under the -fsanitize-memory-use-after-dtor (disabled by default) insert
an MSan runtime library call at the end of every destructor.

Patch by Naomi Musgrave.

llvm-svn: 242097

When using a linker script expression to change the address of a section, even
if the new address is more than a page of distance from the old address, lld
may put everything in the same segment, forcing it to be unnecessarily large.
This patch changes the logic in Segment::assignVirtualAddress() and
Segment::assignFileOffsets() to allow the segment to be sliced into two or more
if it detects a linker script expression that changes a section address.

Differential Revision: http://reviews.llvm.org/D10952

llvm-svn: 242096

llvm-svn: 242095

llvm-svn: 242094

llvm-svn: 242093

llvm-svn: 242092

Previously we would refrain from attempting to increase the linkage of
available_externally globals because they were considered weak for the
linker. Now they are treated more like a declaration instead of a weak
definition.

This was causing SSE alignment faults in Chromuim, when some code
assumed it could increase the alignment of a dllimported global that it
didn't control.  http://crbug.com/509256

llvm-svn: 242091

llvm-svn: 242090

When calculating the start address and size of a segment, lld mistakenly
attributed the start address of the last segment slice to the whole segment
when it should consider the start address of the first slice. In this case, in a
multi-slice segment, Segment::assignVirtualAddress() will return a wrong
segment start address to TargetLayout::assignVirtualAddress(). The effect of
this miscalculation is to allocate some program headers in unnecessarily far
away addresses. This commit fixes this.

Differential Revision: http://reviews.llvm.org/D10951

llvm-svn: 242089

This is a direct port of the new PE/COFF linker to ELF.

It can take a single object file and generate a valid executable that executes at the first byte in the text section.

llvm-svn: 242088

No functionality change is intended.

llvm-svn: 242087

No functionality change intended.

llvm-svn: 242086

  NOTE: reverts r242077 to reinstate r242058, r242065, 242067
        and includes fix for OS X test failures.

  - Changed driver pipeline to compile host and device side of CUDA
    files and incorporate results of device-side compilation into host
    object file.

  - Added a test for cuda pipeline creation in clang driver.

  New clang options:
  --cuda-host-only   - Do host-side compilation only.
  --cuda-device-only - Do device-side compilation only.

  --cuda-gpu-arch=<ARCH> - specify GPU architecture for device-side
    compilation. E.g. sm_35, sm_30. Default is sm_20. May be used more
    than once in which case one device-compilation will be done per
    unique specified GPU architecture.

  Differential Revision: http://reviews.llvm.org/D9509

llvm-svn: 242085