We stopped marking `__lldb_expr` with the function qualifiers of the
method LLDB is stopped in ever since
`8bdcd522510f923185cdfaec66c4a78d0a0d38c0`. The assumption was that it
wasn't ever required for correctness (i.e., LLDB should just always
pretend it's in a mutable context). But since function qualifiers affect
overloading in C++, this assumption can lead to unexpected expression
evaluator behaviour. E.g., if a function is overloaded on qualifiers
(`const` vs. `non-const`), the expression evaluator would currently
always call the non-CV qualified overload.
This patch adds function qualifiers to `$__lldb_class::$__lldb_expr`
that resemble the qualifiers of the method that we're stopped in.
However, mutating variables or calling arbitrary member functions from
CV-qualified methods can be useful/is something users already may be
used to. To provide users with the ability to ignore the CV-qualifiers
of the current context, we will provide an expression evaluator flag
that switches this off in a follow-up patch.
The motivation here is that we don't want to pollute the SBAPI with
getters/setters for expression evaluation options that only apply to a
single language. The ultimate goal would be to have plugins register
additional options to the `expression` command when the plugin is
loaded. This patch only provides the minimal `SBExpressionOptions`
interface to set an option with an arbitrary name, which the language
plugin knows how to interpret. The underlying options dictionary is an
`StructuredData::Dictionary` so we can map strings to values of any
type. But the SBAPI just exposes setting a boolean value. Future
overloads of `SetLanguageOption` can provide setters for more types.
The boolean setter/getter will be used for the C++-specific option being
introduced in: https://github.com/llvm/llvm-project/pull/177926
This reapplies #175292 with the fixed test. The original test used
integer types with different bit widths on different platforms.
----- Original message:
This allows expressions that use these conversions to be executed when
JIT is not available.
Writing testcases for error handling that depends on specific DWARF is
very difficult and the resulting tests tend not to be very portable.
This patch adds a new setting to inject an error into variable
materialization, thus making it possible to write very simple source
code based tests for error handling instead.
This is primarily motivated by the Swift language plugin, but
functionality is generic and should be useful for other languages as
well.
The test will fail if libc++ starts to use a lambda in `<array>`. This
will become the case because
- libc++'s `array::fill` uses `std::fill_n`, and
- `std::fill_n` is to be optimized for segment iterators, and
- the natural approach for such optimization uses lambdas.
Until ASTImport of `clang::LambdaExpr` nodes gets properly fix, this
will need to be skipped.
Depends on:
* https://github.com/llvm/llvm-project/pull/162050
Since it's a 'Note' diagnostic it would only show up when expression
evaluation actually failed. This helps with expression evaluation
failure reports in mixed language environments where it's not quite
clear what language the expression ran as. It may also reduce confusion
around why the expression evaluator ran an expression in a language it
wasn't asked to run (a softer alternative to what I attempted in
https://github.com/llvm/llvm-project/pull/156648).
Here are some example outputs:
```
# Without target
(lldb) expr blah
note: Falling back to default language. Ran expression as 'Objective C++'.
# Stopped in target
(lldb) expr blah
note: Ran expression as 'C++14'.
(lldb) expr -l objc -- blah
note: Expression evaluation in pure Objective-C not supported. Ran expression as 'Objective C++'.
(lldb) expr -l c -- blah
note: Expression evaluation in pure C not supported. Ran expression as 'ISO C++'.
(lldb) expr -l c++14 -- blah
note: Ran expression as 'C++14'
(lldb) expr -l c++20 -- blah
note: Ran expression as 'C++20'
(lldb) expr -l objective-c++ -- blah
note: Ran expression as 'Objective C++'
(lldb) expr -l D -- blah
note: Expression evaluation in D not supported. Falling back to default language. Ran expression as 'Objective C++'.
```
I didn't put the diagnostic on the same line as the inline diagnostic
for now because of implementation convenience, but if reviewers deem
that a blocker I can take a stab at that again.
Also, other language plugins (namely Swift), won't immediately benefit
from this and will have to emit their own diagnistc. I played around
with having a virtual API on `UserExpression` or `ExpressionParser` that
will be called consistently, but by the time we're about to parse the
expression we are already several frames deep into the plugin. Before
(and at the beginning of) the generic `UserExpression::Parse` call we
don't have enough information to notify which language we're going to
parse in (at least for the C++ plugin).
rdar://160297649
rdar://159669244
This reverts commit 76bd5da3248fd4affedfefec3b2a3e1acbe0a94a.
These were originally skipped for
https://github.com/llvm/llvm-project/issues/137046 because they were
failing on Fuchsia buildbots.
I couldn't locally reproduce the Linux failures from back then (and
maybe they have been fixed by something else since then).
We want to re-enable these tests because they are one of the few API
tests in the `libcxx` category that we skip on Linux. So the libc++
pre-merge CI doesn't catch these test failures. To avoid churn caused by
this missing coverage, it would be great if we ran these on Linux again.
Fixes https://github.com/llvm/llvm-project/issues/135707
Follow up to https://github.com/llvm/llvm-project/pull/148836
which fixed some of this issue but not all of it.
Our Value/ValueObject system does not store the endian directly
in the values. Instead it assumes that the endian of the result
of a cast can be assumed to be the target's endian, or the host
but only as a fallback. It assumes the place it is copying from
is also that endian.
This breaks down when you have register values. These are always
host endian and continue to be when cast. Casting them to big
endian when on a little endian host breaks certain calls like
GetValueAsUnsigned.
To fix this, check the context of the value. If it has a register
context, always treat it as host endian and make the result host
endian.
I had an alternative where I passed an "is_register" flag into
all calls to this, but it felt like a layering violation and changed
many more lines.
This solution isn't much more robust, but it works for all the test
cases I know of. Perhaps you can create a register value without
a RegisterInfo backing it, but I don't know of a way myself.
For testing, I had to add a minimal program file for each arch
so that there is a type system to support the casting. This is
generated from YAML since we only need the machine and endian
to be set.
Relates to https://github.com/llvm/llvm-project/issues/135707
Where it was reported that reading the PC using "register read" had
different results to an expression "$pc".
This was happening because registers are treated in lldb as pure
"values" that don't really have an endian. We have to store them
somewhere on the host of course, so the endian becomes host endian.
When you want to use a register as a value in an expression you're
pretending that it's a variable in memory. In target memory. Therefore
we must convert the register value to that endian before use.
The test I have added is based on the one used for XML register flags.
Where I fake an AArch64 little endian and an s390x big endian target. I
set up the data in such a way the pc value should print the same for
both, either with register read or an expression.
I considered just adding a live process test that checks the two are the
same but with on one doing cross endian testing, I doubt it would have
ever caught this bug.
Simulating this means most of the time, little endian hosts will test
little to little and little to big. In the minority of cases with a big
endian host, they'll check the reverse. Covering all the combinations.
This reverts commit 2b4b3fd03f716b9ddbb2a69ccfbe144312bedd12.
Turns out the CI still fails with this test enabled:
```
11:08:50 File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/commands/expression/import-std-module/queue/TestQueueFromStdModule.py", line 37, in test
11:08:50 self.expect_expr(
11:08:50 File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2571, in expect_expr
11:08:50 value_check.check_value(self, eval_result, str(eval_result))
11:08:50 File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 301, in check_value
11:08:50 test_base.assertSuccess(val.GetError())
11:08:50 File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2606, in assertSuccess
11:08:50 self.fail(self._formatMessage(msg, "'{}' is not success".format(error)))
11:08:50 AssertionError: 'error: /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk/usr/include/module.modulemap:93:11: header 'stdarg.h' not found
11:08:50 93 | header "stdarg.h" // note: supplied by the compiler
11:08:50 | ^
11:08:50 /Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/lib/clang/22/include/stdint.h:56:16: submodule of top-level module 'Darwin' implicitly imported here
11:08:50 56 | # include_next <stdint.h>
11:08:50 | ^
11:08:50 error: While building module 'std' imported from <lldb wrapper prefix>:42:
```
Failing on the macOS matrix bot for Clang-15:
```
07:38:40 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/commands/expression/import-std-module/queue/TestQueueFromStdModule.py", line 38, in test
07:38:40 self.expect_expr(
07:38:40 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2571, in expect_expr
07:38:40 value_check.check_value(self, eval_result, str(eval_result))
07:38:40 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 301, in check_value
07:38:40 test_base.assertSuccess(val.GetError())
07:38:40 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2606, in assertSuccess
07:38:40 self.fail(self._formatMessage(msg, "'{}' is not success".format(error)))
07:38:40 AssertionError: 'error: /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk/usr/include/module.modulemap:93:11: header 'stdarg.h' not found
07:38:40 93 | header "stdarg.h" // note: supplied by the compiler
07:38:40 | ^
07:38:40 /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/clang_1501_build/include/c++/v1/ctype.h:38:15: submodule of top-level module 'Darwin' implicitly imported here
07:38:40 38 | #include_next <ctype.h>
07:38:40 | ^
07:38:40 error: While building module 'std' imported from <lldb wrapper prefix>:42:
```
https://github.com/llvm/llvm-project/pull/144913 was reverted because
some of the Darwin tests were failing on SDKs prior to `15.0`.
Only the x86 bots run on macOS `14.0`. The aarch64 ones run on macOS
`15.0`.
In this patch, we deactivate the failing Darwin tests on older SDKs
(prior to `15.0`).
Relates to https://github.com/llvm/llvm-project/issues/22139
Just had to use the right win32 call instead of getpid. The original
problem was something with expressions in general which was
fixed at some point.
Also make the test one method, there's no need to split it up.
Relates to https://github.com/llvm/llvm-project/issues/22139
This used to be broken because the expressions didn't work,
but the test also used getpid which isn't avaialable on Windows.
So when the expressions started working, evaluation still failed
due to getpid.
I made it call GetCurrentProcessId and it worked.
#146562 made
[TestCallStdStringFunction](bd6cd92984/lldb/test/API/commands/expression/call-function/TestCallStdStringFunction.py)
unexpectedly pass on Windows.
The test now passes, because `expression str` now prints the "raw"
string object, which happens to include the string "Hello world".
Previously, this resulted in an error:
```
(lldb) expression str
(std::string) $0 = {
_Mypair = {
_Myval2 = {
_Bx = (_Buf = "Hello world", _Ptr = "", _Alias = "Hello world")
_Mysize = 11
_Myres = 15
}
}
}
(lldb) type summary add std::string --summary-string "${var._M_dataplus._M_p}"
^^^ previous summary ^^^
(lldb) expression str
(std::string) $1 = error: summary string parsing error
```
#143177 will eventually add the correct summary for MSVC STL strings.
Relates to https://github.com/llvm/llvm-project/issues/22139
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.
It's not scientific but I think the PDB we produce on the Windows on Arm
bot simply doesn't have the information needed. Could also be that clang
is producing some DWARF, but link.exe is dropping it from the final executable,
the effect is the same.
When using `SBFrame::EvaluateExpression` on a frame that's not the
currently selected frame, we would sometimes run into errors such as:
```
error: error: The context has changed before we could JIT the expression!
error: errored out in DoExecute, couldn't PrepareToExecuteJITExpression
```
During expression parsing, we call `RunStaticInitializers`. On our
internal fork this happens quite frequently because any usage of, e.g.,
function pointers, will inject ptrauth fixup code into the expression.
The static initializers are run using `RunThreadPlan`. The
`ExecutionContext::m_frame_sp` going into the `RunThreadPlan` is the
`SBFrame` that we called `EvaluateExpression` on. LLDB then tries to
save this frame to restore it after the thread-plan ran (the restore
occurs by unconditionally overwriting whatever is in
`ExecutionContext::m_frame_sp`). However, if the `selected_frame_sp` is
not the same as the `SBFrame`, then `RunThreadPlan` would set the
`ExecutionContext`'s frame to a different frame than what we started
with. When we `PrepareToExecuteJITExpression`, LLDB checks whether the
`ExecutionContext` frame changed from when we initially
`EvaluateExpression`, and if did, bails out with the error above.
One such test-case is attached. This currently passes regardless of the
fix because our ptrauth static initializers code isn't upstream yet. But
the plan is to upstream it soon.
This patch addresses the issue by saving/restoring the frame of the
incoming `ExecutionContext`, if such frame exists. Otherwise, fall back
to using the selected frame.
rdar://147456589
The test checks specific compiler version to determine the output.
However, the compiler version string is always set to 15.0.0 for our
local build. Remove this check and use regex match instead.
## Test Plan
```
./bin/llvm-lit -sva /home/wanyi/llvm-sand/external/llvm-project/lldb/test/API/commands/expression/import-std-module/vector-of-vectors/TestVectorOfVectorsFromStdModule.py
...
Skipping the following test categories: ['dsym', 'gmodules', 'debugserver', 'objc']
--
Command Output (stderr):
--
UNSUPPORTED: LLDB (/home/wanyi/llvm-sand/build/Release+Distribution/fbcode-x86_64/toolchain/bin/clang-x86_64) :: test_dsym (TestVectorOfVectorsFromStdModule.TestVectorOfVectors) (test case does not fall in any category of interest for this run)
PASS: LLDB (/home/wanyi/llvm-sand/build/Release+Distribution/fbcode-x86_64/toolchain/bin/clang-x86_64) :: test_dwarf (TestVectorOfVectorsFromStdModule.TestVectorOfVectors)
PASS: LLDB (/home/wanyi/llvm-sand/build/Release+Distribution/fbcode-x86_64/toolchain/bin/clang-x86_64) :: test_dwo (TestVectorOfVectorsFromStdModule.TestVectorOfVectors)
----------------------------------------------------------------------
Ran 3 tests in 4.636s
OK (skipped=1)
--
********************
Testing Time: 4.97s
Total Discovered Tests: 1
Passed: 1 (100.00%)
```
This patch rewords some of the user expression diagnostics.
- Differentiate between being interrupted and hitting a breakpoint.
- Use "expression execution" to make it more obvious that the diagnostic
is associated with the user expression.
- Consistently use a colon instead of semicolons and commas.
rdar://143059974
Some tests from 'import-std-module' used to fail on the builder
https://lab.llvm.org/staging/#/builders/195/builds/4470,
since libcxx is set up to be linked statically with test binaries
on it.
Thus, they were temporarily disabled in #112530. Here, this commit
is reverted.
Jitted expressions from the tests try to call __libcpp_verbose_abort
function that is not present in the process image, which causes
the failure.
Here, this symbol is explicitly referenced from the test source files.
Fixes
Traceback (most recent call last):
File
"/home/buildbot/worker/as-builder-9/lldb-remote-linux-ubuntu/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 1770, in test_method
return attrvalue(self)
^^^^^^^^^^^^^^^
File
"/home/buildbot/worker/as-builder-9/lldb-remote-linux-ubuntu/llvm-project/lldb/test/API/commands/expression/diagnostics/TestExprDiagnostics.py",
line 255, in test_command_expr_sbdata
self.assertEquals(error.GetType(), lldb.eErrorTypeExpression)
^^^^^^^^^^^^^^^^^
AttributeError: 'ExprDiagnosticsTestCase' object has no attribute
'assertEquals'. Did you mean: 'assertEqual'?
`assertEqual` is a method inherited from `unittest.TestCase`.
See #120784 and
https://github.com/llvm/llvm-project/pull/120784#issuecomment-2557871308
Building on top of previous work that exposed expression diagnostics via
SBCommandReturnObject, this patch generalizes the support to expose any
SBError as machine-readable structured data. One use-case of this is to
allow IDEs to better visualize expression diagnostics.
rdar://139997604
The old behavior was to return a null string in the error case,when
refactoring the error handling I thought it would be a good idea to
print the error in the description, but that breaks clients that try to
print a description first and then do something else in the error case.
The API is not great but it's clear that in-band errors are also not a
good idea.
rdar://133956263
Prior to this patch, the function returned an exit status, sometimes a
ValueObject with an error and a Status object. This patch removes the
Status object and ensures the error is consistently returned as the
error of the ValueObject.
Line ending policies were changed in the parent, dccebddb3b80. To make
it easier to resolve downstream merge conflicts after line-ending
policies are adjusted this is a separate whitespace-only commit. If you
have merge conflicts as a result, you can simply `git add --renormalize
-u && git merge --continue` or `git add --renormalize -u && git rebase
--continue` - depending on your workflow.
