This patch uses SWIG to generate the Lua bindings for the SB API. It
covers most of the API, but some methods require a type map similar to
Python.

Discussion on the mailing list:
http://lists.llvm.org/pipermail/lldb-dev/2019-December/015812.html

Differential revision: https://reviews.llvm.org/D71235

Makes sure that the script works fine both in python2 and python3.

Patch by Pavel Samolysov!

Differential Revision: https://reviews.llvm.org/D71746

Summary:
If none of the input files are ELF object files (for example, when
generating an object file from a single binary input file via
"-b binary"), use a fallback value for the ELF header flags instead
of crashing with an assertion failure.

Reviewers: MaskRay, ruiu, espindola

Reviewed By: MaskRay, ruiu

Subscribers: kevans, grimar, emaste, arichardson, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, llvm-commits, jrtc27

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D71101

We missed a constraint in D44833
when folding a bitcast into a GEP with vector/array types.
If the alloc sizes specified by the datalayout don't match,
this could miscompile as shown in:
https://bugs.llvm.org/show_bug.cgi?id=44321

Differential Revision: https://reviews.llvm.org/D71771

As discussed in PR44330:
https://bugs.llvm.org/show_bug.cgi?id=44330
...the transform from pow(X, -0.5) libcall/intrinsic to
reciprocal square root can result in small deviations from
the expected result due to differences in the pow()
implementation and/or the extra rounding step from the division.

This patch proposes to allow that difference with either the
'approximate functions' or 'reassociate' FMF:
http://llvm.org/docs/LangRef.html#fast-math-flags

In practice, this likely means that the code is compiled with
all of 'fast' (-ffast-math), but I have preserved the existing
specializations for -0.0/-INF that enable generating safe code
if those special values are allowed simultaneously with
allowing approximation/reassociation.

The question about whether a similar restriction is needed for
the non-reciprocal case -- pow(X, 0.5) -- is deferred. That
transform is allowed without FMF currently, and this patch does
not change that behavior.

Differential Revision: https://reviews.llvm.org/D71706

Their naming is misleading as they only return the
ClangASTContext-owned variables. For ClangASTContext instances constructed
for a given clang::ASTContext they silently generated duplicated instances
(e.g., a second IdentifierTable) that were essentially unusable.

This removes all these getters as they are anyway not very useful in comparison
to just calling the clang::ASTContext getters. The initialization
code has been moved to the CreateASTContext initialization method so that all
code for making our own clang::ASTContext is in one place.

We cannot pick reserved registers as rename registers.

Fixes https://bugs.llvm.org/show_bug.cgi?id=44358

This avoids unneeded copies when using a range-based for loops.

This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall.

Differential Revision: https://reviews.llvm.org/D70869

Differential revision: https://reviews.llvm.org/D69223

I'm unable to get this test working there.

After d567b0ba, the test suite no longer
passes if hexagon is disabled.

It does not seem to run automatically on windows.

Reviewers: aaron.ballman

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D71680

The size is known and the truncation is deliberate -- use memcpy instead
of strncpy.

D71372 introduced: `Unwind/thread-step-out-ret-addr-check.test` failing on
Fedora 30 Linux x86_64.
  [lldb] Add additional validation on return address in 'thread step-out'
  https://reviews.llvm.org/D71372

One problem is the underscored `_nonstandard_stub` in the `.s` file but not in
the LLDB command:
  (lldb) breakpoint set -n nonstandard_stub
  Breakpoint 1: no locations (pending).
  WARNING:  Unable to resolve breakpoint to any actual locations.
  (lldb) process launch
  Process 21919 exited with status = 0 (0x00000000)
  Process 21919 launched: '/home/jkratoch/redhat/llvm-monorepo-clangassert/tools/lldb/test/Unwind/Output/thread-step-out-ret-addr-check.test.tmp' (x86_64)
  (lldb) thread step-out
  error: invalid thread
  (lldb) _

Another problem is that Fedora Linux has executable stack by default and all
programs indicate non-executable stack by `PT_GNU_STACK`, after fixing the
underscore I was getting:
  (lldb) thread step-out
  Process 22294 exited with status = 0 (0x00000000)
  (lldb) _

A different approach was tried as:
  [lldb] Refactor thread-step-out-ret-addr-check test to use .data instead of stack variable
  https://reviews.llvm.org/D71789

Differential revision: https://reviews.llvm.org/D71784

  echo -e '#include <unistd.h>\nint main(void){\nsync();return 0;}'|./bin/clang -g -x c -;./bin/lldb -o 'file ./a.out' -o 'b main' -o r -o 'p (void)sync()'

Actual:

  error: Expression can't be run, because there is no JIT compiled function

Expected:

  <nothing, sync() has been executed>

This patch has been checked by:
  D71707: clang-tidy: new bugprone-pointer-cast-widening
  https://reviews.llvm.org/D71707

Casting from 32-bit `void *` to `uint64_t` requires an intermediate `uintptr_t` cast otherwise the pointer gets sign-extended:

  echo -e '#include <stdio.h>\n#include <stdint.h>\nint main(void){void *p=(void *)0x80000000;unsigned long long ull=(unsigned long long)p;unsigned long long ull2=(unsigned long
long)(uintptr_t)p;printf("p=%p ull=0x%llx ull2=0x%llx\\n",p,ull,ull2);return 0;}'|gcc -Wall -m32 -x c -;./a.out
  <stdin>: In function ‘main’:
  <stdin>:3:66: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  p=0x80000000 ull=0xffffffff80000000 ull2=0x80000000

With debug output:
Actual:

  IRMemoryMap::WriteMemory (0xb6ff8640, 0xffffffffb6f82158, 0x112) went to [0xb6ff8640..0xb6ff86b3)
  Code can be run in the target.
  Found function, has local address 0xffffffffb6f84000 and remote address 0xffffffffffffffff
  Couldn't disassemble function : Couldn't find code range for function _Z12$__lldb_exprPv
  Sections:
  [0xb6f84000+0x3c]->0xb6ff9020 (alignment 4, section ID 0, name .text)
  ...
  HandleCommand, command did not succeed
  error: Expression can't be run, because there is no JIT compiled function

Expected:

  IRMemoryMap::WriteMemory (0xb6ff8640, 0xb6faa15c, 0x128) went to [0xb6ff8640..0xb6ff86c3)
  IRExecutionUnit::GetRemoteAddressForLocal() found 0xb6fac000 in [0xb6fac000..0xb6fac040], and returned 0xb6ff9020 from [0xb6ff9020..0xb6ff9060].
  Code can be run in the target.
  Found function, has local address 0xb6fac000 and remote address 0xb6ff9020
  Function's code range is [0xb6ff9020+0x40]
  ...
  Function data has contents:
  0xb6ff9020: 10 4c 2d e9 08 b0 8d e2 08 d0 4d e2 00 40 a0 e1
  ...
  Function disassembly:
  0xb6ff9020: 0xe92d4c10   push   {r4, r10, r11, lr}

Differential revision: https://reviews.llvm.org/D71498

This seems to have been relying on extra spills being inserted in
these blocks to increase the code size to trigger branch
relaxation. This broke when these spills were avoided. Add some asm to
pad the size of the blocks to make it not matter.

Confusingly, the intrinsic operands do not match the
instruction/custom node. The order is shuffled, and the 3rd operand is
an immediate to select operands.

I'm not 100% sure I did this right, but fdiv still doesn't select end
to end and it will be easier to tell when it does. This at least
avoids an assertion in RegBankSelect and allows hitting the fallback
on selection.

This can directly access the register bank, and doesn't need to get it
through the ID.

Reviewed By: mclow.lists

Differential Revision: https://reviews.llvm.org/D71525

Temporarily revert the qsort changes because they fail to build on bots
that build with modules:

> error: thread-local storage is not supported for the current
> target (iossim)

http://green.lab.llvm.org/green/job/clang-stage2-Rthinlto/1820/console
http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/4983/console

This reverts commit ddf897fc.
This reverts commit 07861e95.

The isysroot field in DIModule was renamed to sysroot but the test in
LLDB wasn't updated. This fixes that.

This matches the behavior of the legacy layer, which automatically deregistered
frames.

Add a new decorator that checks if LLDB was build with editline support
and mark the relevant tests as skipped when that's not the case.

Expose all the externally-observable optional dependencies through
SBDebugger::GetBuildConfiguration().

> A macro is executed as if the macro body were pasted in place of the
> calling statement. This has the consequence that a return() in a macro
> body does not just terminate execution of the macro

After converting from a function() to a macro(), the return() became
invalid. This modifies the control flow to elude the return.

Recently there has been some discussion about how we deal with optional
dependencies in LLDB. The approach in LLVM is to make things work out of
the box. If the dependency isn't there, we move on silently.

That's not true for LLDB. Unless you explicitly disable the dependency
with LLDB_ENABLE_*, you'll get a configuration-time error. The
historical reason for this is that LLDB's dependencies have a much
broader impact, think about Python for example which is required to run
the test suite.

The current approach can be frustrating from a user experience
perspective. Sometimes you just want to ensure LLDB builds with a change
in clang.

This patch changes the optional dependencies (with the exception of
Python) to a new scheme. The LLDB_ENABLE_* now takes three values: On,
Off or Auto, with the latter being the default. On and Off behave the
same as today, forcing the dependency to be enabled or disabled. If the
dependency is set to On bu...