See https://reviews.llvm.org/D109572 for the original ELF version.

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

LLDB WoA buildbot is failing due to pid_t redefinition after recent changes in
lldb/source/Plugins/ScriptInterpreter/Python/ScriptedProcessPythonInterface.cpp.
Process.h includes PosixApi.h which defines pid_t. Python.h on windows also typedefs
pid_t. To make sure that we include Python.h before PosixApi this patch renforces
the workaround previously set up to guard this issue.

https://lab.llvm.org/buildbot/#/builders/219

Reviewed By: mib

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

Fixes #60975

Reviewed By: bogner

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

`__sanitizer_report_error_summary` is declared `llvm/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_interface_internal.h` as being able to be overridden by the client. On darwin the sanitizer runtime uses this symbol to find references to the sanitizer libraries, so if you override it you end up with the error `=ERROR: Interceptors are not working. This may be because AddressSanitizer is loaded too late (e.g. via dlopen). Please launch the executable with:` at launch time.

Replace uses of `__sanitizer_report_error_summary` for finding the sanitizer libraries with using the address of a local function.

Reviewed By: yln, vitalybuka

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

This patch should fix a `stack-use-after-scope` in the helper function
`ScriptedInterface::ErrorWithMessage`.

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

These propagate all the way down to SPIR-V and result in some fishy code
with large constants.

Reviewed By: antiagainst

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

The patch uses declval instead of nullptr to suppress warning for calling member
function by nullptr. Also the patch replace is_same<*>::value with is_same_v<*>.

Reviewed By: dexonsmith, kuhar

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

Some workflows can generate large GSYM files and sharding GSYM files into segments can help some performant workflows that can take advantage of smaller GSYM files. This patch add a new --segment-size option to llvm-gsymutil. This option can specify a rough size in bytes of how large each segment should be.

Segmented GSYM files contain only the strings and files that are needed for the FunctionInfo objects that are added to each shard. The output file path gets the first address of the first contained function info appended as a suffix to the filename. If a base address of an image is set in the GsymCreator, then all segments will use this same base address which allows lookups for symbolication to happen correctly when the image has been slid in memory.

Code has been addeed to refactor and re-use methods within the GsymCreator to allow for segments to be created easily and tested.

Example of segmenting GSYM files:

$ llvm-gsymutil --convert llvm-gsymutil.dSYM -o llvm-gsymutil.gsym --segment-size 10485760
$ ls -l llvm-gsymutil.gsym-*
-rw-r--r--  1 gclayton  staff  10485839 Feb  9 10:45 llvm-gsymutil.gsym-0x1000030c0
-rw-r--r--  1 gclayton  staff  10485765 Feb  9 10:45 llvm-gsymutil.gsym-0x100668888
-rw-r--r--  1 gclayton  staff  10485881 Feb  9 10:45 llvm-gsymutil.gsym-0x100c948b8
-rw-r--r--  1 gclayton  staff  10485954 Feb  9 10:45 llvm-gsymutil.gsym-0x101659e70
-rw-r--r--  1 gclayton  staff  10485792 Feb  9 10:45 llvm-gsymutil.gsym-0x1022b1dc0
-rw-r--r--  1 gclayton  staff  10485889 Feb  9 10:45 llvm-gsymutil.gsym-0x102a18b10
-rw-r--r--  1 gclayton  staff  10485893 Feb  9 10:45 llvm-gsymutil.gsym-0x1030b05d0
-rw-r--r--  1 gclayton  staff  10485802 Feb  9 10:45 llvm-gsymutil.gsym-0x1037caaac
-rw-r--r--  1 gclayton  staff  10485781 Feb  9 10:45 llvm-gsymutil.gsym-0x103e767a0
-rw-r--r--  1 gclayton  staff  10485832 Feb  9 10:45 llvm-gsymutil.gsym-0x10452d0d4
-rw-r--r--  1 gclayton  staff  10485782 Feb  9 10:45 llvm-gsymutil.gsym-0x104b93310
-rw-r--r--  1 gclayton  staff   6255785 Feb  9 10:45 llvm-gsymutil.gsym-0x10526bf34

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

The usage was removed in https://reviews.llvm.org/D119074

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

This reverts commit 599b7690. Since
adding a cross project dependency is a concern.

Typically names longer than -non-global-value-max-name-size will just get renamed if there is a collision after truncating. This is fine since we typically don't reference Values by name.

However LLParser does reference Values by name, so report an error when that happens, otherwise weird issues can crop up if there are name collisions (e.g. verifier issues with the changed test case because we end up reusing the same block for `testz` and `testa`).

Reviewed By: nikic

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

Reviewed By: david-arm, fhahn

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

This reverts commit 436ea548.

This extends the patterns for loading into the zeroth lane of a zero vector
from D144086 to SVE, which work in the same way as the existing patterns. Only
full length vectors are added here, not the narrower floating point vector
types.

This reverts commit a00801d9.

Broke TestVSCode_completions.py

Memory functions get the basic implementation. They can be tuned
as a follow up.

Reviewed By: michaelrj, lntue

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

Reviewed By: michaelrj

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

Reviewed By: aartbik, Peiming

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

This ALIAS option is now used with threads/callonce target.

Reviewed By: lntue

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

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

This patch fixes:

  mlir/lib/Dialect/SparseTensor/IR/SparseTensorDialect.cpp:675:56:
  error: comparison of integers of different signs: 'long const' and
  'const mlir::sparse_tensor::Level' (aka 'const unsigned long')
  [-Werror,-Wsign-compare]

IRBuilder in many cases is able to fold constant code automatically,
but in some cases (for some intrinsics) it cannot do it. Need to perform
manual calculation, if constant provided in these corner cases, to avoid
infinite loop.

Cbrt can be approximated with some relatively simple polynomial
operators. This includes a lit test validating the implementation
and some run tests that validate numerical correct.

Reviewed By: jpienaar

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

This change replaces the binary profiles and executables used for
testing the memprof profile reader with tests where the profiles are
generated on the fly. This reduces toil when the profile version
changes. The tests are moved from tools/llvm-profdata to
compiler-rt/test/memprof due to the following reasons:
1. Adding dependency on memprof lit.cfg.py for llvm-profdata is
   preferable to adding a dependency on compiler-rt for llvm/test.
2. All the tests can now be run with `ninja check-memprof`.

Reviewed By: tejohnson

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

This reverts commit 70b9822e.

This reverts commit cfe06f49.

This reverts commit 3c33d72e.

This reverts commit 3675e0bb.

This patch moves `ScriptedMetadata.h` from the `Interpreter` directory to
the `Utility` sub-directory since `ProcessInfo.h` depends on it.

It also gets rid of the unused `OptionGroupPythonClassWithDict`
constructor for `ScriptedMetadata` which would address the layering
violation.

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

This patch is a proof of concept that shows how a scripted process could
be used with real process to perform interactive debugging.

In this example, we run a process that spawns 10 threads. Then, we
create a intermediary scripted process who's job will be to wrap the
real process while intercepting it's process events and dispatching them
back either to the real process or to other child scripted processes.

In this example, we have 2 child scripted processes, with even and odd
thread indices. The goal is to be able to do thread filtering and
explore the various interactive debugging approaches, by letting a child
process running when stopping the other process and inspecting it.
Another approach would be to have the child processes execution in-sync
to force running every child process when one of them starts running.

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

This patch adds support for breakpoint setting to Scripted Processes.

For now, Scripted Processes only support setting software breakpoints.

When doing interactive scripted process debugging, it makes use of the
memory writing capability to write the trap opcodes in the memory of the
driving process. However the real process' target doesn't keep track of
the breakpoints that got added by the scripted process. This is a design
that we might need to change in the future, since we'll probably need to
do some book keeping to handle breakpoints that were set by different
scripted processes.

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



Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

While debugging a Scripted Process, in order to update its state and
work nicely with lldb's execution model, it needs to toggle its private
state from running to stopped, which will result in broadcasting a
process state changed event to the debugger listener.

Originally, this state update was done systematically in the Scripted
Process C++ plugin, however in order to make scripted process
interactive, we need to be able to update their state dynamically.

This patch makes use of the recent addition of the
`SBProcess::ForceScriptedState` to programatically, and moves the
process private state update to the python implementation of the `resume`
method instead of doing it in `ScriptedProcess::DoResume`.

This patch also removes the unused `ShouldStop` & `Stop` scripted
process APIs, and adds new ScriptedInterface transform methods for
boolean arguments. This allow the user to programmatically decide if
after running the process, we should stop it (which is the default setting).

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



Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

This patch introduces a new method to the SBProcess API called
ForceScriptedState. As the name suggests, this affordance will allow the
user to alter the private state of the scripted process programatically.

This is necessary to update the scripted process state when perform
interactive debugging.

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



Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

The l_brace of class/struct/union was incorrectly annotated as
TT_FunctionLBrace in the presence of attributes. This in turn
would cause the RemoveSemicolon option to remove the semicolon
at the end of the declaration, resulting in invalid code being
generated.

Fixes #61188.

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

Redefine the `p` alias to the `dwim-print` command instead of `expression`.

See https://reviews.llvm.org/D138315 for the introduction of `dwim-print`.

To summarize, `dwim-print` is, as the name suggests, a command for printing. How a value
gets printed, is decided by `dwim-print`. In some cases, `dwim-print` will print values
using the same means as `frame variable` (because it's generally more reliable and
faster that `expression` evaluation), and in other cases `dwim-print` uses the same code
path as `expression`.

This change has been tested in two different ways:

1. Re-aliasing `p` to `dwim-print`, as in this patch
2. Redefinining the `expression` command to `CommandObjectDWIMPrint`

Previously, many of the lldb's tests used `p`, and which meant a test run with `p`
aliases to `dwim-print` was a good way to test `dwim-print`. However most of those tests
were updated to use `expression` explicitly (in anticipation of this change). Now, the
best way to test `dwim-print` is the second approach:

```
diff --git a/lldb/source/Interpreter/CommandInterpreter.cpp b/lldb/source/Interpreter/CommandInterpreter.cpp
index 373c894f34f5..9c943cd30c7c 100644
--- a/lldb/source/Interpreter/CommandInterpreter.cpp
+++ b/lldb/source/Interpreter/CommandInterpreter.cpp
@@ -539,7 +539,7 @@ void CommandInterpreter::LoadCommandDictionary() {
   REGISTER_COMMAND_OBJECT("diagnostics", CommandObjectDiagnostics);
   REGISTER_COMMAND_OBJECT("disassemble", CommandObjectDisassemble);
   REGISTER_COMMAND_OBJECT("dwim-print", CommandObjectDWIMPrint);
-  REGISTER_COMMAND_OBJECT("expression", CommandObjectExpression);
+  REGISTER_COMMAND_OBJECT("expression", CommandObjectDWIMPrint);
   REGISTER_COMMAND_OBJECT("frame", CommandObjectMultiwordFrame);
   REGISTER_COMMAND_OBJECT("gui", CommandObjectGUI);
   REGISTER_COMMAND_OBJECT("help", CommandObjectHelp);
```

When the test suite is run with this change, there are two main categories of test
failures for specific to features that `dwim-print` intentionally doesn't support:

1. Top level expressions (`--top-level`/`-p`)
2. Multiline expressions

In cases where the behavior of `expression` is needed, users can use `expression` at
those times.

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

The old "pointer/index" names often cause confusion since these names clash with names of unrelated things in MLIR; so this change rectifies this by changing everything to use "position/coordinate" terminology instead.

In addition to the basic terminology, there have also been various conventions for making certain distinctions like: (1) the overall storage for coordinates in the sparse-tensor, vs the particular collection of coordinates of a given element; and (2) particular coordinates given as a `Value` or `TypedValue<MemRefType>`, vs particular coordinates given as `ValueRange` or similar.  I have striven to maintain these distinctions
as follows:

  * "p/c" are used for individual position/coordinate values, when there is no risk of confusion.  (Just like we use "d/l" to abbreviate "dim/lvl".)

  * "pos/crd" are used for individual position/coordinate values, when a longer name is helpful to avoid ambiguity or to form compound names (e.g., "parentPos").  (Just like we use "dim/lvl" when we need a longer form of "d/l".)

    I have also used these forms for a handful of compound names where the old name had been using a three-letter form previously, even though a longer form would be more appropriate.  I've avoided renaming these to use a longer form purely for expediency sake, since changing them would require a cascade of other renamings.  They should be updated to follow the new naming scheme, but that can be done in future patches.

  * "coords" is used for the complete collection of crd values associated with a single element.  In the runtime library this includes both `std::vector` and raw pointer representations.  In the compiler, this is used specifically for buffer variables with C++ type `Value`, `TypedValue<MemRefType>`, etc.

    The bare form "coords" is discouraged, since it fails to make the dim/lvl distinction; so the compound names "dimCoords/lvlCoords" should be used instead.  (Though there may exist a rare few cases where is is appropriate to be intentionally ambiguous about what coordinate-space the coords live in; in which case the bare "coords" is appropriate.)

    There is seldom the need for the pos variant of this notion.  In most circumstances we use the term "cursor", since the same buffer is reused for a 'moving' pos-collection.

  * "dcvs/lcvs" is used in the compiler as the `ValueRange` analogue of "dimCoords/lvlCoords".  (The "vs" stands for "`Value`s".)  I haven't found the need for it, but "pvs" would be the obvious name for a pos-`ValueRange`.

    The old "ind"-vs-"ivs" naming scheme does not seem to have been sustained in more recent code, which instead prefers other mnemonics (e.g., adding "Buf" to the end of the names for `TypeValue<MemRefType>`).  I have cleaned up a lot of these to follow the "coords"-vs-"cvs" naming scheme, though haven't done an exhaustive cleanup.

  * "positions/coordinates" are used for larger collections of pos/crd values; in particular, these are used when referring to the complete sparse-tensor storage components.

    I also prefer to use these unabbreviated names in the documentation, unless there is some specific reason why using the abbreviated forms helps resolve ambiguity.

In addition to making this terminology change, this change also does some cleanup along the way:
  * correcting the dim/lvl terminology in certain places.
  * adding `const` when it requires no other code changes.
  * miscellaneous cleanup that was entailed in order to make the proper distinctions.  Most of these are in CodegenUtils.{h,cpp}

Reviewed By: aartbik

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

Per discussions with @erichkeane.

Add basic tests for `frame variable`'s ability to direct access fields of `this` and
ivars of `self`.

This splits the tests, preventing ObjC tests from running on Linux.

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

Make `zip_common` increment and decrement iterators in place.

This improves performance with iterator types that have non-triviall
copy constructors.

Reviewed By: zero9178

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