| Age | Commit message (Collapse) | Author |
|---|
|
Introduces `_regexp-step`, a step command which additionally allows for
stepping into a target function. This change updates `step` and `s` to
be aliases for `_regexp-step`.
The existing `sif` alias ("Step Into Function") is not well known
amongst users. This change updates `step` and `s` to also work like
`sif`, taking an optional function name.
This is implemented to not break uses of `step` or `s` with a flag, for
example running `step -r func_to_avoid` works as expected.
|
|
When I wrote this previously, I was unaware that the TLS function
already adds the offset. The test was working previously because the
offset was 0 in this case (only 1 thread-local variable). I added
another thread-local variable to the test to make sure the offset is
indeed handled correctly.
rdar://156547548
|
|
Since https://github.com/llvm/llvm-project/pull/141344, they are
passing.
|
|
The architectures provided to skipIf / expectedFail are regular
expressions (v. _match_decorator_property() in decorators.py
so on Darwin systems "arm64" would match the skips for "arm" (32-bit
Linux). Update these to "arm$" to prevent this, and also update
three tests (TestBuiltinFormats.py, TestCrossDSOTailCalls.py,
TestCrossObjectTailCalls.py) that were skipped for arm64 via this
behavior, and need to be skipped or they will fail.
This was moviated by the new TestDynamicValue.py test which has
an expected-fail for arm, but the test was passing on arm64 Darwin
resulting in failure for the CIs.
|
|
With our Clang-15 arm64 CI this test-case crashes when compiling the test program:
```
user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/c/calling-conventions/ms_abi.c
Unexpected callee-save save/restore opcode!
UNREACHABLE executed at /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/clang_1501/llvm/lib/Target/AArch64/AArch64FrameLowering.cpp:1129!
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/clang_1501_build/bin/clang -g -O0 -isysroot /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk -arch arm64 -I/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/make/../../../../..//include -I/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/lldb-build/tools/lldb/include -I/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/c/calling-conventions -I/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/make -include /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/make/test_common.h -fno-limit-debug-info -Werror=ignored-attributes -MT ms_abi.o -MD -MP -MF ms_abi.d -c -o ms_abi.o /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/c/calling-conventions/ms_abi.c
1. <eof> parser at end of file
2. Code generation
3. Running pass 'Function Pass Manager' on module '/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/c/calling-conventions/ms_abi.c'.
4. Running pass 'Prologue/Epilogue Insertion & Frame Finalization' on function '@func'
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
0 clang-15 0x0000000105d512b0 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 56
1 clang-15 0x0000000105d500e4 llvm::sys::RunSignalHandlers() + 112
2 clang-15 0x0000000105d507c4 llvm::sys::CleanupOnSignal(unsigned long) + 232
3 clang-15 0x0000000105c79d78 (anonymous namespace)::CrashRecoveryContextImpl::HandleCrash(int, unsigned long) + 128
4 clang-15 0x0000000105c79f94 CrashRecoverySignalHandler(int) + 124
5 libsystem_platform.dylib 0x0000000185ecba24 _sigtramp + 56
6 libsystem_pthread.dylib 0x0000000185e9ccc0 pthread_kill + 288
7 libsystem_c.dylib 0x0000000185daca40 abort + 180
8 clang-15 0x0000000105c88508 llvm::install_out_of_memory_new_handler() + 0
9 clang-15 0x0000000104af7404 fixupCalleeSaveRestoreStackOffset(llvm::MachineInstr&, unsigned long long, bool, bool*) + 0
10 clang-15 0x0000000104af53e0 llvm::AArch64FrameLowering::emitPrologue(llvm::MachineFunction&, llvm::MachineBasicBlock&) const + 3564
```
|
|
Co-authored-by: Eisuke Kawashima <e-kwsm@users.noreply.github.com>
|
|
Add a pythonic `stop_reason_data` property to `SBThread`. The property
produces a list of ints.
|
|
Following up from https://github.com/llvm/llvm-project/pull/112342, we
roll out the fix and quote nested `make` invocations in all API tests.
|
|
This has been flakey lately for example:
https://lab.llvm.org/buildbot/#/builders/18/builds/5139
|
|
|
|
ConstantArrayType (#100710)
Depends on https://github.com/llvm/llvm-project/pull/100674
Currently, we treat VLAs declared as `int[]` and `int[0]` identically.
I.e., we create them as `IncompleteArrayType`s. However, the
`DW_AT_count` for `int[0]` *does* exist, and is retrievable without an
execution context. This patch decouples the notion of "has 0 elements"
from "has no known `DW_AT_count`".
This aligns with how Clang represents `int[0]` in the AST (it treats it
as a `ConstantArrayType` of 0 size).
This issue was surfaced when adapting LLDB to
https://github.com/llvm/llvm-project/issues/93069. There, the
`__compressed_pair_padding` type has a `char[0]` member. If we
previously got the `__compressed_pair_padding` out of a module (where
clang represents `char[0]` as a `ConstantArrayType`), and try to merge
the AST with one we got from DWARF (where LLDB used to represent
`char[0]` as an `IncompleteArrayType`), the AST structural equivalence
check fails, resulting in silent ASTImporter failures. This manifested
in a failure in `TestNonModuleTypeSeparation.py`.
**Implementation**
1. Adjust `ParseChildArrayInfo` to store the element counts of each VLA
dimension as an `optional<uint64_t>`, instead of a regular `uint64_t`.
So when we pass this down to `CreateArrayType`, we have a better
heuristic for what is an `IncompleteArrayType`.
2. In `TypeSystemClang::GetBitSize`, if we encounter a
`ConstantArrayType` simply return the size that it was created with. If
we couldn't determine the authoritative bound from DWARF during parsing,
we would've created an `IncompleteArrayType`. This ensures that
`GetBitSize` on arrays with `DW_AT_count 0x0` returns `0` (whereas
previously it would've returned a `std::nullopt`, causing that
`FieldDecl` to just get dropped during printing)
|
|
This is a fixup to https://github.com/llvm/llvm-project/pull/93808,
which used LDFLAGS instead of the correct LD_EXTRAS
|
|
When PIE is enabled on a platform by default, these tests fail since the
`target variable` command can't read a global string variable value
before running an inferior process.
It fixes the following tests when built with clang on Ubuntu aarch64:
```
commands/target/basic/TestTargetCommand.py
lang/c/global_variables/TestGlobalVariables.py
lang/cpp/char8_t/TestCxxChar8_t.py
```
|
|
Rewrite an inline test as an API test, to be a little easier to debug,
and add some additional checks that we're in the inlined test1, then
step and we are now in the inlined test2 functions.
|
|
On Windows the function does not have a symbol associated with it:
Function: id = {0x000001c9}, name = "_Dfunction", range =
[0x0000000140001000-0x0000000140001004)
LineEntry: <...>
Whereas it does on Linux:
Function: id = {0x00000023}, name = "_Dfunction", range =
[0x0000000000000734-0x0000000000000738)
LineEntry: <...>
Symbol: id = {0x00000058}, range =
[0x0000000000000734-0x0000000000000738), name="_Dfunction"
This means that frame.symbol is not valid on Windows.
However, frame.function is valid and it also has a "mangled" attribute.
So I've updated the test to check the symbol if we've got it, and the
function always.
In both cases we check that mangled is empty (meaning it has not been
treated as mangled) and that the display name matches the original
symbol name.
|
|
|
|
While the fix is reviewed.
|
|
Reduce false positive identification of C names as Dlang mangled names. This happens
when a C function uses the prefix `_D`.
The [Dlang ABI](https://dlang.org/spec/abi.html#name_mangling) shows that mangled names
have a length immediately following the `_D` prefix. This change checks for a digit
after the `_D` prefix, when identifying the mangling scheme of a symbol. This doesn't
prevent false positives entirely, but does make it less likely.
|
|
| is a reserved character in regex.
|
|
This relates to #56084.
vectorcall only works on x86
https://clang.llvm.org/docs/AttributeReference.html#vectorcall so
elsewhere it fails to compile. Which is expected on AArch64 for example
so is treated as a pass.
|
|
When Apple released its new linker, it had a subtle bug that caused
LLDB's TLS tests to fail. Unfortunately this means that TLS tests are
not going to work on machines that have affected versions of the linker,
so we should annotate the tests so that they only work when we are
confident the linker has the required fix.
I'm not completely satisfied with this implementation. That being said,
I believe that adding suport for linker versions in general is a
non-trivial change that would require far more thought. There are a few
challenges involved:
- LLDB's testing infra takes an argument to change the compiler, but
there's no way to switch out the linker.
- There's no standard way to ask a compiler what linker it will use.
- There's no standard way to ask a linker what its version is. Many
platforms have the same name for their linker (ld).
- Some platforms automatically switch out the linker underneath you. We
do this for Windows tests (where we use LLD no matter what).
Given that this is affecting the tests on our CI, I think this is an
acceptable solution in the interim.
|
|
This reverts commit 3434472ed74141848634b5eb3cd625d651e22562.
Closes #43097.
|
|
This uses [teyit](https://pypi.org/project/teyit/) to modernize asserts,
as recommended by the [unittest release
notes](https://docs.python.org/3.12/whatsnew/3.12.html#id3).
For example, `assertTrue(a == b)` is replaced with `assertEqual(a, b)`.
This produces better error messages, e.g. `error: unexpectedly found 1
and 2 to be different` instead of `error: False`.
|
|
assertEquals is a deprecated alias for assertEqual and has been removed
in Python 3.12. This wasn't an issue previously because we used a
vendored version of the unittest module. Now that we use the built-in
version this gets updated together with the Python version used to run
the test suite.
|
|
This removes the dependency LLDB API tests have on
lldb/third_party/Python/module/unittest2, and instead uses the standard
one provided by Python.
This does not actually remove the vendored dep yet, nor update the docs.
I'll do both those once this sticks.
Non-trivial changes to call out:
- expected failures (i.e. "bugnumber") don't have a reason anymore, so
those params were removed
- `assertItemsEqual` is now called `assertCountEqual`
- When a test is marked xfail, our copy of unittest2 considers failures
during teardown to be OK, but modern unittest does not. See
TestThreadLocal.py. (Very likely could be a real bug/leak).
- Our copy of unittest2 was patched to print all test results, even ones
that don't happen, e.g. `(5 passes, 0 failures, 1 errors, 0 skipped,
...)`, but standard unittest prints a terser message that omits test
result types that didn't happen, e.g. `OK (skipped=1)`. Our lit
integration parses this stderr and needs to be updated w/ that
expectation.
I tested this w/ `ninja check-lldb-api` on Linux. There's a good chance
non-Linux tests have similar quirks, but I'm not able to uncover those.
|
|
|
|
Recently added TLS linux support fails on Arm/AArch64. I am skiping test
for now and will investigate the issue later.
|
|
This patch implements the thread local storage support for linux
(https://github.com/llvm/llvm-project/issues/28766).
TLS feature is originally only implemented for Mac. With my previous
patch to enable `fs_base` register for Linux
(https://reviews.llvm.org/D155256), now it is feasible to implement this
feature for Linux.
The major changes are:
* Track the main module's link address during launch
* Fetch thread pointer from `fs_base` register
* Create register alias for thread pointer
* Read pthread metadata from target memory instead of process so that it
works for coredump
With the patch the failing test is passing now. Note: I am only enabling
this test for Mac and Linux because I do not have machine to test for
FreeBSD/NetBSD.
---------
Co-authored-by: jeffreytan81 <jeffreytan@fb.com>
|
|
This reverts commit 6ea1a0d4fc3823de143a288df2059b48dc01cf72.
It again marks XFAIL LLDB tests failing after
c384fcd3ea1dad782eaaea89b32fc33c0c3528b8
|
|
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
|
|
This patch add or removes XFAIL decorator from various tests which were marked
xfail for windows.
since 44363f2 various tests have started passing but introduced a couple of new failures.
Weight is in favor of new XPasses and I have removed XFail decorator from them. Also
some new tests have started failing for which we need to file separate bugs. I have
marked them xfail for now and will add the bug id after investigating the issue.
Differential Revision: https://reviews.llvm.org/D149235
|
|
|
|
|
|
In API tests, replace use of the `p` alias with the `expression` command.
To avoid conflating tests of the alias with tests of the expression command,
this patch canonicalizes to the use `expression`.
Differential Revision: https://reviews.llvm.org/D141539
|
|
The original code always set the m_live_address of children of the ValueObjects that
use ValueObjectConstResultImpl backends to the parent m_live_address + child_byte_offset.
That is correct for structure types, but wrong for pointer types, since m_live_address
for a pointer type is the address of the storage for the pointer, not of the pointee.
Also added a test which was failing before this patch.
|
|
DWARFExpression::Evaluate will convert DW_OP_addr addresses in
a DWARF expression into load addresses on the expression stack
when there is a StackFrame in the ExecutionContext, this from
a change in 2018 in https://reviews.llvm.org/D46362. At the
time this was handling a case that came up in swift programs,
and is no longer necessary. I generalized this conversion to
a load address when a Target is available in
https://reviews.llvm.org/D137682 to make a test case possible;
this change broke a use case that Ted reported.
This change removes my test case, and removes this conversion
of a DW_OP_addr into a load address in some instances.
Differential Revision: https://reviews.llvm.org/D139226
|
|
When we cannot allocate memory in the inferior process, the IR
interpreter's IRMemoryMap::FindSpace will create an lldb local
buffer and assign it an address range in the inferior address
space. When the interpreter sees an address in that range, it
will read/write from the local buffer instead of the target. If
this magic address overlaps with actual data in the target, the
target cannot be accessed through expressions.
Instead of using a high memory address that is validly addressable,
this patch uses an address that cannot be accessed on 64-bit systems
that don't actually use all 64 bits of the virtual address.
Differential Revision: https://reviews.llvm.org/D137682
rdar://96248287
|
|
Using the more specific assert* methods results in more useful error message.
|
|
|
|
|
|
Currently, SymbolFileDWARFDebugMap works on the assumption that there is
only one compile unit per object file. This patch documents this
limitation (when using the general SymbolFile API), and allows users of
the concrete SymbolFileDWARFDebugMap class to find out about these extra
compile units.
Differential Revision: https://reviews.llvm.org/D136114
|
|
This reverts commit a0fb69d17b4d7501a85554010727837340e7b52f.
This broke the windows lldb bot: https://lab.llvm.org/buildbot/#/builders/83/builds/23666
|
|
Patch enables handing of DWARFv5 DW_MACRO_define_strx and DW_MACRO_undef_strx
~~~
OS Laboratory. Huawei RRI. Saint-Petersburg
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D130062
|
|
Patch sets ARM cpu, before compiling JIT code. This enables FastISel for armv6 and higher CPUs and allows using hardware FPU
~~~
OS Laboratory. Huawei RRI. Saint-Petersburg
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D131783
|
|
Not needed now that we require python 3.
Reviewed By: kastiglione, JDevlieghere
Differential Revision: https://reviews.llvm.org/D131761
|
|
When targeting macOS Ventura, ld64 will use authenticated fixups for
x86_64 as well as arm64 (where that has always been the case). This
results in test failures when using an Xcode 14 toolchain on an Intel
mac running macOS Ventura:
Failed Tests (3):
lldb-api :: commands/target/basic/TestTargetCommand.py
lldb-api :: lang/c/global_variables/TestGlobalVariables.py
lldb-api :: lang/cpp/char8_t/TestCxxChar8_t.py
Rather than trying to come up with a sophisticated decorator based off
the deployment target, I marked them all as skipped with a comment
explaining why.
Differential revision: https://reviews.llvm.org/D131741
|
|
|
|
Test was introduced in https://reviews.llvm.org/D126359
~~~
OS Laboratory. Huawei RRI. Saint-Petersburg
|
|
Patch adds support for fadd, fsub, fdiv, fmul and fcmp to IR interpreter.
~~~
OS Laboratory. Huawei RRI. Saint-Petersburg
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D126359
|
|
This test was disabled because clang struggled to emit a Windows calling
convention when targeting an Apple environment. This test is now showing
up as an XPASS so someone must have fixed this.
|
