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 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
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 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
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).
This adds SBBreakpoint::SetIsHardware, allowing clients to mark an
existing breakpoint as a hardware breakpoint purely through the API.
This is safe to do after creation, as the hardware/software distinction
doesn't affect how breakpoint locations are selected.
In some cases (e.g. when writing a trap instruction would alter program
behavior), it's important to use hardware breakpoints. Ideally, we’d
extend the various `Create` methods to support this, but given their
number, this patch limits the scope to the post-creation API. As a
workaround, users can also rely on target.require-hardware-breakpoint or
use the `breakpoint set` command.
rdar://153528045
Terminal resizing continues to be a source of statusline bugs, so much
so that some users have started disabling it altogether. Different
operating systems and terminal emulators exhibit subtly different
behaviors, making it nearly impossible to handle resizing reliably
across the board.
This patch sidesteps those issues by clearing the entire screen when the
terminal is resized. This avoids having to account for the previous,
potentially wrapped statusline, the underlying cause of many of the
aforementioned bugs.
The obvious downside is that this clears the on-screen history, but I
believe that’s a reasonable trade-off. Note that this only happens when
resizing the terminal; when launching LLDB, the statusline is drawn
without clearing the screen.
rdar://154778410
The libstdc++ test was a subset of the tests in libc++. This test moves
the libc++ test into `generic` and removes the `libstdc++` tests. I
retained the `-D_GLIBCXX_DEBUG` test cases though.
Split out from https://github.com/llvm/llvm-project/pull/146740
Previously the parameter wasn't respected. So we would only run the test
with whatever stdlib the `Makefile.rules` deduced.
Confirmed that
```
lldb-dotest -p TestDataFormatterGenericSet.py --category libstdcxx
```
passes on my machine.
When there is a function that is inlined at the current program counter.
If you get the current `line_entry` using the program counter's address
it will point to the location of the inline function that may be in
another file. (this is in implicit step-in and should not happen what
step over is called).
Use the current frame to get the `line_entry`
It looks like #146603 broke the
[lldb-remote-linux-win](https://lab.llvm.org/buildbot/#/builders/197)
build bot because `MCPUnixSocketCommandTestCase` is trying to start a
protocol-server via unix domain sockets on windows.
This change makes it so the test is skipped if it is remote.
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
When starting an MCP protocol server that uses unix sockets as the
transport, a local `'[0.0.0.0]:0'` file is used instead of the supplied
socket path, e.g:
```
(lldb) protocol-server start MCP accept:///tmp/some/path.sock
MCP server started with connection listeners: unix-connect://[0.0.0.0]:0
(lldb) shell ls '[*'
[0.0.0.0]:0
```
This change makes it so that the URI path is used if the socket protocol
is `ProtocolUnixDomain`:
```
(lldb) protocol-server start MCP accept:///tmp/some/path.sock
MCP server started with connection listeners: unix-connect:///tmp/some/path.sock
```
The plan is to move all STL formatter API tests into a single directory.
The `std::deque` test is currently the only test that is duplicated
between the `libcxx` and `generic` directories. This patch moves the
libcxx deque tests into `generic` (moving over any functionality that
wasn't tested in the `generic` tests, mainly formatting
pointers/references to `std::deque`).
