[lldb][test] Use `xcrun -f strip` for API tests on Darwin (#111842)

A follow-up for https://github.com/llvm/llvm-project/pull/111816.

This is to fix buildbot failure
https://lab.llvm.org/staging

[lldb][test] Use `xcrun -f strip` for API tests on Darwin (#111842)

A follow-up for https://github.com/llvm/llvm-project/pull/111816.

This is to fix buildbot failure
https://lab.llvm.org/staging/#/builders/195/builds/4242.

TestSymbolFileJSON.py doesn't pass with llvm-strip on macOS. Apparently,
llvm-strip/llvm-objcopy can't clean symbols from Mach-O nlists.

show more ...

[lldb][test] Use $(STRIP) instead of strip in API tests (Darwin-only change) (#111816)

This makes tests more portable.
Make variables for LLVM utils are passed to `make` on Darwin as well.

Co-au

[lldb][test] Use $(STRIP) instead of strip in API tests (Darwin-only change) (#111816)

This makes tests more portable.
Make variables for LLVM utils are passed to `make` on Darwin as well.

Co-authored-by: Vladimir Vereschaka <vvereschaka@accesssoftek.com>

show more ...

[lldb][test] Provide proper path to LLVM utils in API tests (#110837)

In aea066849, API tests were supposed to use LLVM tools.
However, a path to a utility is made up incorrectly there: util name

[lldb][test] Provide proper path to LLVM utils in API tests (#110837)

In aea066849, API tests were supposed to use LLVM tools.
However, a path to a utility is made up incorrectly there: util name
should be prefixed with `llvm-`.

Hence, it's fixed here.

show more ...

[lldb][test] Use tools from llvm instead of compiler tools (#109961)

In #102185, toolchain detection for API tests has been rewritten in
Python. Tools paths for tests there are determined from comp

[lldb][test] Use tools from llvm instead of compiler tools (#109961)

In #102185, toolchain detection for API tests has been rewritten in
Python. Tools paths for tests there are determined from compiler path.

Here tools are taken from `--llvm-tools-dir` dotest.py argument, which
by default refers to the LLVM build directory, unless they are
explicitly redefined in environment variables. It helps to minimize
external dependencies and to maximize the reproducibility of the build.

show more ...

[lldb][test] Toolchain detection rewrite in Python (#102185)

This fix is based on a problem with cxx_compiler and cxx_linker macros
on Windows.
There was an issue with compiler detection in paths

[lldb][test] Toolchain detection rewrite in Python (#102185)

This fix is based on a problem with cxx_compiler and cxx_linker macros
on Windows.
There was an issue with compiler detection in paths containing "icc". In
such case, Makefile.rules thought it was provided with icc compiler.

To solve that, utilities detection has been rewritten in Python.
The last element of compiler's path is separated, taking into account
the platform path delimiter, and compiler type is extracted, with regard
of possible cross-toolchain prefix.

---------

Co-authored-by: Pavel Labath <pavel@labath.sk>

show more ...

[lldb][test] Add --make argument to dotest.py (#93883)

This argument allows to specify the path to make which is used by
LLDB API tests to compile test programs.
It might come in handy for setting u

[lldb][test] Add --make argument to dotest.py (#93883)

This argument allows to specify the path to make which is used by
LLDB API tests to compile test programs.
It might come in handy for setting up cross-platform remote runs of API tests on Windows host.

It can be used to override the make path of LLDB API tests using `LLDB_TEST_USER_ARGS` argument:
```
cmake ...
-DLLDB_TEST_USER_ARGS="...;--make;C:\\Path\\to\\make.exe;..."
...
```

show more ...

Install generated API headers into LLDB.framework (#90666)

[NFC][Py Reformat] Reformat python files in lldb

This is an ongoing series of commits that are reformatting our Python
code. Reformatting is done with `black` (23.1.0).

If you end up having problem

[NFC][Py Reformat] Reformat python files in lldb

This is an ongoing series of commits that are reformatting our Python
code. Reformatting is done with `black` (23.1.0).

If you end up having problems merging this commit because you have made
changes to a python file, the best way to handle that is to run `git
checkout --ours <yourfile>` and then reformat it with black.

RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style

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

show more ...

[test] Fix LLDB tests with just-built libcxx when using a target directory.

In certain configurations, libc++ headers all exist in the same directory, and libc++ binaries exist in the same directory

[test] Fix LLDB tests with just-built libcxx when using a target directory.

In certain configurations, libc++ headers all exist in the same directory, and libc++ binaries exist in the same directory as lldb libs. When `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR` is enabled (*and* the host is not Apple, which is why I assume this wasn't caught by others?), this is not the case: most headers will exist in the usual `include/c++/v1` directory, but `__config_site` exists in `include/$TRIPLE/c++/v1`. Likewise, the libc++.so binary exists in `lib/$TRIPLE/`, not `lib/` (where LLDB libraries reside).

This also adds the just-built-libcxx functionality to the lldb-dotest tool.

The `LIBCXX_` cmake config is borrowed from `libcxx/CMakeLists.txt`. I could not figure out a way to share the cmake config; ideally we would reuse the same config instead of copy/paste.

Reviewed By: JDevlieghere, fdeazeve

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

show more ...

Add the ability to show when variables fails to be available when debug info is valid.

Summary:
Many times when debugging variables might not be available even though a user can successfully set bre

Add the ability to show when variables fails to be available when debug info is valid.

Summary:
Many times when debugging variables might not be available even though a user can successfully set breakpoints and stops somewhere. Letting the user know will help users fix these kinds of issues and have a better debugging experience.

Examples of this include:
- enabling -gline-tables-only and being able to set file and line breakpoints and yet see no variables
- unable to open object file for DWARF in .o file debugging for darwin targets due to modification time mismatch or not being able to locate the N_OSO file.

This patch adds an new API to SBValueList:

lldb::SBError lldb::SBValueList::GetError();

object so that if you request a stack frame's variables using SBValueList SBFrame::GetVariables(...), you can get an error the describes why the variables were not available.

This patch adds the ability to get an error back when requesting variables from a lldb_private::StackFrame when calling GetVariableList.

It also now shows an error in response to "frame variable" if we have debug info and are unable to get varialbes due to an error as mentioned above:

(lldb) frame variable
error: "a.o" object from the "/tmp/libfoo.a" archive: either the .o file doesn't exist in the archive or the modification time (0x63111541) of the .o file doesn't match

Reviewers: labath JDevlieghere aadsm yinghuitan jdoerfert sscalpone

Subscribers:

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

show more ...

Revert "Add the ability to show when variables fails to be available when debug info is valid."

This reverts commit 9af089f5179d52c6561ec27532880edcfb6253af.

This broke the windows lldb bot: https:

Revert "Add the ability to show when variables fails to be available when debug info is valid."

This reverts commit 9af089f5179d52c6561ec27532880edcfb6253af.

This broke the windows lldb bot: https://lab.llvm.org/buildbot/#/builders/83/builds/23528

show more ...

Add the ability to show when variables fails to be available when debug info is valid.

Many times when debugging variables might not be available even though a user can successfully set breakpoints

Add the ability to show when variables fails to be available when debug info is valid.

Many times when debugging variables might not be available even though a user can successfully set breakpoints and stops somewhere. Letting the user know will help users fix these kinds of issues and have a better debugging experience.

Examples of this include:
- enabling -gline-tables-only and being able to set file and line breakpoints and yet see no variables
- unable to open object file for DWARF in .o file debugging for darwin targets due to modification time mismatch or not being able to locate the N_OSO file.

This patch adds an new API to SBValueList:

lldb::SBError lldb::SBValueList::GetError();

object so that if you request a stack frame's variables using SBValueList SBFrame::GetVariables(...), you can get an error the describes why the variables were not available.

This patch adds the ability to get an error back when requesting variables from a lldb_private::StackFrame when calling GetVariableList.

It also now shows an error in response to "frame variable" if we have debug info and are unable to get varialbes due to an error as mentioned above:

(lldb) frame variable
error: "a.o" object from the "/tmp/libfoo.a" archive: either the .o file doesn't exist in the archive or the modification time (0x63111541) of the .o file doesn't match

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

show more ...

[lldb] Support specifying a custom libcxx for the API tests

This patch combines D129166 (to always pick the just-built libc++) and
D132257 (to allow customizing the libc++ for testing). The common g

[lldb] Support specifying a custom libcxx for the API tests

This patch combines D129166 (to always pick the just-built libc++) and
D132257 (to allow customizing the libc++ for testing). The common goal
is to avoid picking up an unexpected libc++ for testing.

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

show more ...

[lldb] Use the just-built libc++ for testing the LLDB data formatters

Make sure we use the libc++ from the build dir. Currently, by passing
-stdlib=libc++, we might pick up the system libc++. This c

[lldb] Use the just-built libc++ for testing the LLDB data formatters

Make sure we use the libc++ from the build dir. Currently, by passing
-stdlib=libc++, we might pick up the system libc++. This change ensures
that if LLVM_LIBS_DIR is set, we try to use the libc++ from there.

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

show more ...

[lldb/test] Print build commands in trace mode

Running tests with -t prints all lldb commands being run. It makes sense
to print all the build commands as well.

Differential Revision: https://revie

[lldb/test] Print build commands in trace mode

Running tests with -t prints all lldb commands being run. It makes sense
to print all the build commands as well.

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

show more ...

[lldb] Pass the target triple when determining the DWARF version

When targeting iOS, the default dwarf version is 2 and not 4. Currently,
the test suite does not pick up on that because it invokes t

[lldb] Pass the target triple when determining the DWARF version

When targeting iOS, the default dwarf version is 2 and not 4. Currently,
the test suite does not pick up on that because it invokes the test
compiler without a target triple. This patch fixes that and now
correctly skips tests that have a dwarf version specified in a skipIf
decorator.

rdar://84530477

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

show more ...

[lldb/test] Remove quote/unquote steps from the make invocations

None of the commands we run really rely on shell features. Running them
with shell=False, simplifies the code as there is no need for

[lldb/test] Remove quote/unquote steps from the make invocations

None of the commands we run really rely on shell features. Running them
with shell=False, simplifies the code as there is no need for elaborate
quoting.

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

show more ...

[lldb] Reduce code duplication around inferior building

We had two sets of build<flavour> methods, whose bodies were largely
identical. This makes any kind of modification in their vicinity
repetiti

[lldb] Reduce code duplication around inferior building

We had two sets of build<flavour> methods, whose bodies were largely
identical. This makes any kind of modification in their vicinity
repetitive and error-prone.

Replace each set with a single method taking an optional debug_info
parameter.

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

show more ...

Reland [lldb] Explicitly use the configuration architecture when building test executables

This originally broke the TestQuoting which explicitly called buildDefault
instead of calling build() and m

Reland [lldb] Explicitly use the configuration architecture when building test executables

This originally broke the TestQuoting which explicitly called buildDefault
instead of calling build() and marking the test as no_debug_info_test.
TestQuoting has been rewritten by now and is using `build`, so this should now
pass on all platforms.

Original summary:

The Darwin builder currently assumes in `getArchCFlags` that the passed `arch`
value is an actual string it can string.join with vendor/os/version/env strings:

```
triple = '-'.join([arch, vendor, os, version, env])
```

However this is not true for most tests as we just pass down the `arch=None`
default value from `TestBase.build`. This causes that if we actually end up in
this function we just error out when concatenating `None` with the other actual
strings of vendor/os/version/env. What we should do instead is check that if
there is no test-specific architecture that we fall back to the configuration's
architecture value.

It seems we already worked around this in `builder.getArchSpec` by explicitly
falling back to the architecture specified in the configuration.

This patch just moves this fallback logic to the top `build` function so that it
affects all functions called from `TestBase.build`.

Reviewed By: JDevlieghere

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

show more ...

Revert "[lldb] Explicitly use the configuration architecture when building test executables"

This reverts commit 41185226f6d80663b4a1064c6f47581ee567d78d.

Causes TestQuoting to fail on Windows.

[lldb] Explicitly use the configuration architecture when building test executables

The Darwin builder currently assumes in `getArchCFlags` that the passed `arch`
value is an actual string it can st

[lldb] Explicitly use the configuration architecture when building test executables

The Darwin builder currently assumes in `getArchCFlags` that the passed `arch`
value is an actual string it can string.join with vendor/os/version/env strings:

```
triple = '-'.join([arch, vendor, os, version, env])
```

However this is not true for most tests as we just pass down the `arch=None`
default value from `TestBase.build`. This causes that if we actually end up in
this function we just error out when concatenating `None` with the other actual
strings of vendor/os/version/env. What we should do instead is check that if
there is no test-specific architecture that we fall back to the configuration's
architecture value.

It seems we already worked around this in `builder.getArchSpec` by explicitly
falling back to the architecture specified in the configuration.

This patch just moves this fallback logic to the top `build` function so that it
affects all functions called from `TestBase.build`.

Reviewed By: JDevlieghere

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

show more ...

[lldb] Return empty string from getExtraMakeArgs when not implemented

No return statement means the method returns None which breaks a list
comprehension down the line that expects a str instance.

[lldb] Extend Darwin builder to pass the ARCH_CFLAGS spec to Make.

Construct the ARCH_CFLAGS in Python rather than in Make by disassembling
the TRIPLE.

Differential revision: https://reviews.llvm.o

[lldb] Extend Darwin builder to pass the ARCH_CFLAGS spec to Make.

Construct the ARCH_CFLAGS in Python rather than in Make by disassembling
the TRIPLE.

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

show more ...

[lldb] Add getExtraMakeArgs to Builder (NFC)

Instead of a new method for each variable any subclass might want to
set, have a method getExtraMakeArgs that each subclass can use to return
whatever ex

[lldb] Add getExtraMakeArgs to Builder (NFC)

Instead of a new method for each variable any subclass might want to
set, have a method getExtraMakeArgs that each subclass can use to return
whatever extra Make arguments it wants.

As per Pavel's suggestion in D85539.

show more ...

[lldb] Fix buildDsym signature in Builder base class

The method was missing the optional argument `testname`.