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...

Constrain the macho-stabs test added in f72d001e to run on systems configured with an x86 backend.

Summary: This fixes a failure on the Builder clang-cmake-armv7-quick bot.

Reviewers: lhames, jhenderson

Reviewed By: lhames

Subscribers: kristof.beyls, rupprecht, seiya, llvm-commits

Tags: #llvm

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

There are tests in the included patch, but the duplication is non obvious, so I'm starting with basic coverage beore cleaning up a few of them

These tests are deliberately mismatching new and delete, so the warnings
are just noise.

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

Having this function be recursive could use up way too much stack space.

Rewrite it as an iterative traversal in the tree instead to prevent this.

Fixes PR44344.

The flag is being lost during type legalization or lowering. This
covers some of the cases. I'm sure there are many missing.

This addresses an issue introduced in dedad08e and is needed to make
sure this test works properly on Windows.

This is failing on both the Windows and Debian bot.

It isn't necessary to create DIEs for all of the declaration subprograms
in a CU's retainedTypes list. We can defer creating these subprograms
until we need to prepare a call site tag that refers to one.

This cleanup was mentioned in passing in D70350.

This allows a call site tag in CU A to reference a callee DIE in CU B
without resorting to creating an incomplete duplicate DIE for the callee
inside of CU A.

We already allow cross-CU references of subprogram declarations, so it
doesn't seem like definitions ought to be special.

This improves entry value evaluation and tail call frame synthesis in
the LTO setting. During LTO, it's common for cross-module inlining to
produce a call in some CU A where the callee resides in a different CU,
and there is no declaration subprogram for the callee anywhere. In this
case llvm would (unnecessarily, I think) emit an empty DW_TAG_subprogram
in order to fill in the call site tag. That empty 'definition' defeats
entry value evaluation etc., because the debugger can't figure out what
it means.

As a follow-up, maybe we could add a DWARF verifier check that a
DW_TAG_subprogram at least has a DW_AT_name attribute.

Update:

Reland with a fix to create a declaration DIE when the declaration is
missing from the CU's retainedTypes list. The declaration is left out
of the retainedTypes list in two cases:

1) Re-compiling pre-r266445 bitcode (in which declarations weren't added
   to the retainedTypes list), and
2) Doing LTO function importing (which doesn't update the retainedTypes
   list).

It's possible to handle (1) and (2) by modifying the retainedTypes list
(in AutoUpgrade, or in the LTO importing logic resp.), but I don't see
an advantage to doing it this way, as it would cause more DWARF to be
emitted compared to creating the declaration DIEs lazily.

Tested with a stage2 ThinLTO+RelWithDebInfo build of clang, and with a
ReleaseLTO-g build of the test suite.

rdar://46577651, rdar://57855316, rdar://57840415

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

Summary:
llvm-objdump will commonly error out when disassembling a Mach-O binary with
stab symbols, or when printing a Mach-O symbol table that includesstab symbols.
That is because the Mach-O N_OSO symbol has been modified to include the
bottom 8-bit value of the Mach-O's cpusubtype value in the section field. In
general, one cannot blindly assume a stab symbol's section field is valid
unless one has actually consulted the specification for the specific stab.

Since objdump mostly just walks the symbol table to get mnemonics for code
disassembly it's best for objdump to just ignore stab symbols. llvm-nm will
do a more complete and correct job of displaying Mach-O symbol table contents.

Reviewers: pete, lhames, ab, thegameg, jhenderson, MaskRay

Reviewed By: thegameg, MaskRay

Subscribers: MaskRay, rupprecht, seiya, llvm-commits

Tags: #llvm

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

Extends DWARF expression language to express locals/globals locations. (via
target-index operands atm) (possible variants are: non-virtual registers
or address spaces)

The WebAssemblyExplicitLocals can replace virtual registers to targertindex
operand type at the time when WebAssembly backend introduces
{get,set,tee}_local instead of corresponding virtual registers.

Reviewed By: aprantl, dschuff

Tags: #debug-info, #llvm

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

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

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 but is not found, it results in a configuration
time warning. For Auto we detect if the dependency is there and either
enable or disable it depending on whether it's found.

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

PS: The reason Python isn't included yet is because it's so pervasive
that I plan on doing that in a separate patch.

Recent versions of the iOS simulator require that a "simulator device"
is booted before we can use `simctl spawn` (see iossim_run.py) to start
processes.

We can use `simctl bootstatus` to ensure that the simulator device
is booted before we run any tests via lit.  The `-b` option starts the
device if necessary.

Reviewed By: delcypher

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