LLDB breakpoint conditions take an expression that's evaluated using the
language of the code where the breakpoint is located. Users have asked
to have an option to tell it to evaluate the expression in a specific
language.
This is feature is especially helpful for Swift, for example for a
condition based on the value in memory at an offset from a register.
Such a condition is pretty difficult to write in Swift, but easy in C.
This PR adds a new argument (-Y) to specify the language of the
condition expression. We can't reuse the current -L option, since you
might want to break on only Swift symbols, but run a C expression there
as per the example above.
rdar://146119507
This adds new protocol types for the 'variables' request.
While implementing this, I removed the '$__lldb_extension' field we
returned on the 'variables' request, since I think all the data can be
retrieved from other DAP requests.
---------
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
This just moves the test from `libcxx` to `generic`. There are currently
no `std::function` formatters for libstdc++ so I didn't add a test-case
for it.
Split out from https://github.com/llvm/llvm-project/pull/146740
This RP changes some Breakpoint-related interfaces to return errors. On
its own these improvements are small, but they encourage better error
handling going forward. There are a bunch of other candidates, but these
were the functions that I touched while working on #146602.
Relands the commit to upstream the lldb-rpc-gen tool in order to fix a
build failure on the linux remote bots. The reland adds the Clang
resource dir unconditionally to the invocation for the tool instead of
only adding it in the event that we're using a standalone build.
Original PR description:
This commit upstreams the lldb-rpc-gen tool, a ClangTool that generates
the LLDB RPC client and server interfaces. This tool, as well as LLDB
RPC itself is built by default. If it needs to be disabled, put
-DLLDB_BUILD_LLDBRPC=OFF in your CMake invocation.
https://discourse.llvm.org/t/rfc-upstreaming-lldb-rpc/85804
Original PR Link:
https://github.com/llvm/llvm-project/pull/138031
Enable SWIG support for translating Doxygen comments found in interface
and header files into a target language's normal documentation language.
This feature was introduced in SWIG 4.0 and currently only supports
Python (and Java). Hand-written documentation still takes precedence.
SWIG documentation: https://www.swig.org/Doc4.0/Doxygen.html
This just moves the test from `libcxx` to `generic`. There are currently
no `std::initializer_list` formatters for libstdc++ so I didn't add a
test-case for it.
Split out from https://github.com/llvm/llvm-project/pull/146740
This just moves the test from `libcxx` to `generic`. There are currently
no `std::ranges::ref_view` formatters for libstdc++ so I didn't add a
test-case for it.
Split out from https://github.com/llvm/llvm-project/pull/146740
Now that most STL formatter tests have been moved to `generic`. Do the
same for the MSVC tests (which are currently just for `std::string`).
The `std::string` test was mostly the same (MSVC just had 1 additional
check, which I moved over).
We also only tested `u8string` with MSVC. So i moved those into
`generic` as-is. I kept it separate from the existing std::string tests
since it requires c++20.
The tests are currently failing for libc++ and libstdc++ because MSVC
had a test case which checked that:
```
std::string overwritten_zero("abc");
const_cast<char *>(overwritten_zero.data())[3] = 'd';
```
prints as `"abc"`. But libc++ and libstdc++ print it as `"abcd"` (which
seems like the more correct thing to do?)
This just moves the test from `libcxx` to `generic`. There are currently
no `std::valarray` formatters for libstdc++ so I didn't add a test-case
for it.
Split out from https://github.com/llvm/llvm-project/pull/146740
… directory
This just moves the test from `libcxx` to `generic`. There are currently
no `std::unordered_map::iterator` formatters for libstdc++ so I didn't
add a test-case for it.
Split out from https://github.com/llvm/llvm-project/pull/146740
This just moves the test from `libcxx` to `generic`. There are currently
no `std::span` formatters for libstdc++ so I didn't add a test-case for
it.
Split out from https://github.com/llvm/llvm-project/pull/146740
This just moves the test from `libcxx` to `generic`. There are currently
no `std::string_view` formatters for libstdc++ so I didn't add a
test-case for it.
Split out from https://github.com/llvm/llvm-project/pull/146740
Commands that take an address expression/address through the
OptionArgParser::ToAddress method, which has filtered this
user-specified address through one of the Process Fix methods to clear
non-addressable bits (MTE, PAC, top byte ignore, etc). We don't know
what class of address this is, IMEM or DMEM, but this method is passing
the addresses through Process::FixCodeAddress, and on at least one
target, FixCodeAddress clears low bits which are invalid for
instructions.
Correct this to use FixAnyAddress, which doesn't make alignment
assumptions.
The actual issue found was by people debugging on a 32-bit ARM Cortex-M
part, who tried to do a memory read from an odd address, and lldb
returned results starting at the next lower even address.
rdar://154885727
Working in the Breakpoint library is a minefield if you have your editor
configured to trim trailing whitespace. Remove it and format the
affected lines.
This patch fixes:
third-party/unittest/googletest/include/gtest/gtest.h:1379:11:
error: comparison of integers of different signs: 'const unsigned
long' and 'const int' [-Werror,-Wsign-compare]
This should improve synchronizing the MainLoopWindows monitor thread
with the main loop state.
This uses the `m_ready` and `m_event` event handles to manage when the
Monitor thread continues and adds new tests to cover additional use
cases.
I believe this should fix#147291 but it is hard to ensure a race
condition is fixed without running the CI on multiple
machines/configurations.
---------
Co-authored-by: Pavel Labath <pavel@labath.sk>
This just moves the test from `libcxx` to `generic`. There are currently
no `std::queue` formatters for libstdc++ so I didn't add a test-case for
it.
Split out from https://github.com/llvm/llvm-project/pull/146740
Follow-up to
https://github.com/llvm/llvm-project/pull/147165#pullrequestreview-2992585513
Currently when we explicitly dereference a std::shared_ptr, both the
libstdc++ and libc++ formatters will cast the type of the synthetic
pointer child to whatever the `std::shared_ptr::element_type` is aliased
to. E.g.,
```
(lldb) v p
(std::shared_ptr<int>) p = 10 strong=1 weak=0 {
pointer = 0x000000010016c6a0
}
(lldb) v *p
(int) *p = 10
```
However, when we print (or dereference) `p.pointer`, the type devolves
to something less user-friendly:
```
(lldb) v p.pointer
(std::shared_ptr<int>::element_type *) p.pointer = 0x000000010016c6a0
(lldb) v *p.pointer
(std::shared_ptr<int>::element_type) *p.pointer = 10
```
This patch changes both formatters to store the casted type. Then
`GetChildAtIndex` will consistently use the unwrapped type.
This combines the libc++ and libstdc++ test cases. The main difference
was that the libstdcpp tests had additional tests for
references/pointers to std::string. I moved those over.
The libstdc++ formatters don't support `std::u16string`/`std::u32string`
yet, so I extracted those into XFAILed test cases.
There were also two test assertions that failed for libstdc++:
1. libstdc++ doesn't obey the capped/uncapped summary options
2. When a summary isn't available for a std::string, libc++ would print
"Summary Unavailable", whereas libstdc++ just prints "((null))". This
may be better suited for the STL-specific subdirectories, but left it
here for now.
I put those in separate XFAILed test-cases.
Split out from https://github.com/llvm/llvm-project/pull/146740
This combines the libc++ and libstdc++ test cases. The libstdc++ test
had an additional test-case for "reference to typedef". So I added those
to the generic test. The rest of the tests was the same as libc++.
I also moved the test-case for checking invalid variant indexes into a
separate libstdcpp test because it relied on the layout of the libstdc++
type. We should probably rewrite it in the "simulator" style. But for
now I just moved it.
This also removes some redundant checks for libc++ versions and
existence of the `variant` header, which at this point should be
available anywhere these tests are run.
Split out from https://github.com/llvm/llvm-project/pull/146740
This PR adds type summaries for
`std::{string,wstring,u8string,u16string,u32string}` from the MSVC STL.
See https://github.com/llvm/llvm-project/issues/24834 for the MSVC STL
issue.
The following changes were made:
- `dotest.py` now detects if the MSVC STL is available. It does so by
looking at the target triple, which is an additional argument passed
from Lit. It specifically checks for `windows-msvc` to not match on
`windows-gnu` (i.e. MinGW/Cygwin).
- (The main part): Added support for summarizing `std::(w)string` from
MSVC's STL. Because the type names from the libstdc++ (pre C++ 11)
string types are the same as on MSVC's STL, `CXXCompositeSummaryFormat`
is used with two entries, one for MSVC's STL and one for libstdc++.
With MSVC's STL, `std::u{8,16,32}string` is also handled. These aren't
handled for libstdc++, so I put them in `LoadMsvcStlFormatters`.
This combines the libc++ and libstdc++ test cases. The main difference
was that the libstdcpp tests had some tuple indexing tests that libc++
didn't have.
The libstdc++ formatter didn't support size summaries for std::tuple. So
I added a `ContainerSizeSummaryProvider` for it (like we do for libc++).
Additionally, the synthetic frontend would only apply to non-empty
tuples, so I adjusted the regex to match empty ones too. We do this for
libc++ already.
Split out from https://github.com/llvm/llvm-project/pull/146740
### Summary
Currently `target modules dump separate separate-debug-info`
automatically loads up all DWO files, even if deferred loading is
enabled through debug_names. Then, as expected all DWO files (assuming
there is no error loading it), get marked as "loaded".
This change adds the option `--force-load-all-debug-info` or `-f` for
short to force loading all debug_info up, if it hasn't been loaded yet.
Otherwise, it will change default behavior to not load all debug info so
that the correct DWO files will show up for each modules as "loaded" or
not "loaded", which could be helpful in cases where we want to know
which particular DWO files were loaded.
### Testing
#### Unit Tests
Added additional unit tests
`test_dwos_load_json_with_debug_names_default` and
`test_dwos_load_json_with_debug_names_force_load_all` to test both
default behavior and loading with the new flag
`--force-load-all-debug-info`, and changed expected behavior in
`test_dwos_loaded_symbols_on_demand`.
```
bin/lldb-dotest -p TestDumpDwo ~/llvm-project/lldb/test/API/commands/target/dump-separate-debug-info/dwo
```
#### Manual Testing
Compiled a simple binary w/ `--gsplit-dwarf --gpubnames` and loaded it
up:
```
(lldb) target create "./a.out"
Current executable set to '/home/qxy11/hello-world/a.out' (x86_64).
(lldb) help target modules dump separate-debug-info
List the separate debug info symbol files for one or more target modules.
Syntax: target modules dump separate-debug-info <cmd-options> [<filename> [<filename> [...]]]
Command Options Usage:
target modules dump separate-debug-info [-efj] [<filename> [<filename> [...]]]
-e ( --errors-only )
Filter to show only debug info files with errors.
-f ( --force-load-all-debug-info )
Load all debug info files.
-j ( --json )
Output the details in JSON format.
This command takes options and free-form arguments. If your arguments resemble option specifiers (i.e., they start with a - or --), you must use ' -- ' between the end of the
command options and the beginning of the arguments.
(lldb) target modules dump separate-debug-info --j
[
{
"separate-debug-info-files": [
{ ...
"dwo_name": "main.dwo",
"loaded": false
},
{ ...
"dwo_name": "foo.dwo",
"loaded": false
},
{ ...
"dwo_name": "bar.dwo",
"loaded": false
}
],
}
]
(lldb) b main
Breakpoint 1: where = a.out`main + 15 at main.cc:3:12, address = 0x00000000000011ff
(lldb) target modules dump separate-debug-info --j
[
{
"separate-debug-info-files": [
{ ...
"dwo_name": "main.dwo",
"loaded": true,
"resolved_dwo_path": "/home/qxy11/hello-world/main.dwo"
},
{ ...
"dwo_name": "foo.dwo",
"loaded": false
},
{ ...
"dwo_name": "bar.dwo",
"loaded": false
}
],
}
]
(lldb) b foo
Breakpoint 2: where = a.out`foo(int) + 11 at foo.cc:12:11, address = 0x000000000000121b
(lldb) target modules dump separate-debug-info --j
[
{
"separate-debug-info-files": [
{ ...
"dwo_name": "main.dwo",
"loaded": true,
"resolved_dwo_path": "/home/qxy11/hello-world/main.dwo"
},
{ ...
"dwo_name": "foo.dwo",
"loaded": true,
"resolved_dwo_path": "/home/qxy11/hello-world/foo.dwo"
},
{ ...
"dwo_name": "bar.dwo",
"loaded": false
}
],
}
]
(lldb) b bar
Breakpoint 3: where = a.out`bar(int) + 11 at bar.cc:10:9, address = 0x000000000000126b
(lldb) target modules dump separate-debug-info --j
[
{
"separate-debug-info-files": [
{ ...
"dwo_name": "main.dwo",
"loaded": true,
"resolved_dwo_path": "/home/qxy11/hello-world/main.dwo"
},
{ ...
"dwo_name": "foo.dwo",
"loaded": true,
"resolved_dwo_path": "/home/qxy11/hello-world/foo.dwo"
},
{ ...
"dwo_name": "bar.dwo",
"loaded": true,
"resolved_dwo_path": "/home/qxy11/hello-world/bar.dwo"
}
],
}
]
```
This commit upstreams the LLDB RPC server interface emitters. These
emitters generate the server-side API interfaces for RPC, which
communicate directly with liblldb itself out of process using the SB
API.
https://discourse.llvm.org/t/rfc-upstreaming-lldb-rpc/85804
This combines the libc++ and libstdc++ test cases. The libstdcpp tests
were a subset of the libc++ test, so this patch moves the libcxx test
into `generic` and removes the libstdcpp test entirely.
Split out from https://github.com/llvm/llvm-project/pull/146740
As a pre-requisite to combine the libcxx and libstdcxx string formatter
tests (see https://github.com/llvm/llvm-project/pull/146740) this patch
splits out the libcxx specific parts into a separate test.
These are probably best tested with the libcxx-simulator tests. But for
now I just moved them.
The libc++ test was a subset of the tests in libstdc++. This test moves
the libc++ test into `generic` and somne additional test-cases from
`libstdc++` (specifically the recursive unique_ptr case). It turns out
the libstdc++ formatter supports dereferencing using the "object" or
"obj" names. We could either drop those from the tests or support the
same for libc++. I took the latter approach but don't have strong
opinions on this.
Split out from https://github.com/llvm/llvm-project/pull/146740
This combines the libc++ and libstdc++ test cases. The libstdcpp tests
were a subset of the libc++ test, so this patch moves the libcxx test
into generic and removes the libstdcpp test entirely.
Split out from https://github.com/llvm/llvm-project/pull/146740
This patch adjusts the libcxx and libstdcxx std::shared_ptr formatters
to look the same.
Changes to libcxx:
* Now creates a synthetic child called `pointer` (like we already do for
`std::unique_ptr`)
Changes to libstdcxx:
* When asked to dereference the pointer, cast the type of the result
ValueObject to the element type (which we get from the template argument
to std::shared_ptr).
Before:
```
(std::__shared_ptr<int, __gnu_cxx::_S_atomic>::element_type) *foo = 123
```
After:
```
(int) *foo = 123
```
Tested in https://github.com/llvm/llvm-project/pull/147141
This re-uses the `LibcxxContainerSummaryProvider` for the libstdc++
formatters. There's a couple of containers that aren't making use of it
for libstdc++. This patch will make it easier to review when adding
those in the future.
The libc++ and libstdc++ tests were pretty much an exact copy of each
other. This test moves the libc++ test into generic removes it from
libstdc++. I moved the `GLIBCXX_DEBUG` case over from libstdcxx. For
some reason the libstdcxx test was skipped, but it passes on my Linux
machine. So I unskipped it for now.
Split out from https://github.com/llvm/llvm-project/pull/146740
Currently failing on the arm64 macOS CI with:
```
06:59:37 Traceback (most recent call last):
06:59:37 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/llvm-project/lldb/test/API/commands/frame/var-dil/basics/GlobalVariableLookup/TestFrameVarDILGlobalVariableLookup.py", line 47, in test_frame_var
06:59:37 self.expect_var_path("ExtStruct::static_inline", value="16")
06:59:37 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2589, in expect_var_path
06:59:37 value_check.check_value(self, eval_result, str(eval_result))
06:59:37 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 301, in check_value
06:59:37 test_base.assertSuccess(val.GetError())
06:59:37 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2597, in assertSuccess
06:59:37 self.fail(self._formatMessage(msg, "'{}' is not success".format(error)))
06:59:37 AssertionError: '<user expression 0>:1:1: use of undeclared identifier 'ExtStruct::static_inline'
06:59:37 1 | ExtStruct::static_inline
06:59:37 | ^' is not success
06:59:37 Config=arm64-/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/lldb-build/bin/clang
06:59:37 ----------------------------------------------------------------------
06:59:37 Ran 1 test in 2.322s
06:59:37
```
Can't repro this locally so skipping on older macOS versions that the CI
is running.
The only difference is that with libc++ the summary string contains the
derefernced pointer value. With libstdc++ we currently display the
pointer itself, which seems redundant. E.g.,
```
(std::unique_ptr<int>) iup = 0x55555556d2b0 {
pointer = 0x000055555556d2b0
}
(std::unique_ptr<std::basic_string<char> >) sup = 0x55555556d2d0 {
pointer = "foobar"
}
```
This patch moves the logic into a common helper that's shared between
the libc++ and libstdc++ formatters.
After this patch we can combine the libc++ and libstdc++ API tests (see
https://github.com/llvm/llvm-project/pull/146740).
Reverts llvm/llvm-project#138031. This is failing during the build phase
on the Ubuntu buildbot:
```
Error while processing /home/buildbot/worker/as-builder-9/lldb-remote-linux-ubuntu/llvm-project/lldb/include/lldb/API/SBWatchpoint.h.
[78/78] Processing file /home/buildbot/worker/as-builder-9/lldb-remote-linux-ubuntu/llvm-project/lldb/include/lldb/API/SBWatchpointOptions.h.
warning: unknown warning option '-Wno-maybe-uninitialized'; did you mean '-Wno-uninitialized'? [-Wunknown-warning-option]
warning: unknown warning option '-Wno-class-memaccess'; did you mean '-Wno-class-varargs'? [-Wunknown-warning-option]
warning: unknown warning option '-Wno-stringop-truncation'; did you mean '-Wno-format-truncation'? [-Wunknown-warning-option]
warning: unknown warning option '-Wno-maybe-uninitialized'; did you mean '-Wno-uninitialized'? [-Wunknown-warning-option]
warning: unknown warning option '-Wno-class-memaccess'; did you mean '-Wno-class-varargs'? [-Wunknown-warning-option]
warning: unknown warning option '-Wno-stringop-truncation'; did you mean '-Wno-format-truncation'? [-Wunknown-warning-option]
In file included from /home/buildbot/worker/as-builder-9/lldb-remote-linux-ubuntu/llvm-project/lldb/include/lldb/API/SBWatchpointOptions.h:12:
In file included from /home/buildbot/worker/as-builder-9/lldb-remote-linux-ubuntu/llvm-project/lldb/include/lldb/API/SBDefines.h:12:
In file included from /home/buildbot/worker/as-builder-9/lldb-remote-linux-ubuntu/llvm-project/lldb/include/lldb/lldb-defines.h:12:
In file included from /home/buildbot/worker/as-builder-9/lldb-remote-linux-ubuntu/llvm-project/lldb/include/lldb/lldb-types.h:12:
/home/buildbot/worker/as-builder-9/lldb-remote-linux-ubuntu/llvm-project/lldb/include/lldb/lldb-enumerations.h:12:10: fatal error: 'cstdint' file not found
12 | #include <cstdint>
| ^~~~~~~~~
```
This commit upstreams the `lldb-rpc-gen` tool, a ClangTool that
generates the LLDB RPC client and server interfaces. This tool, as well
as LLDB RPC itself is built by default. If it needs to be disabled, put
-DLLDB_BUILD_LLDBRPC=OFF in your CMake invocation.
https://discourse.llvm.org/t/rfc-upstreaming-lldb-rpc/85804
