First added in #153585 for Darwin only. All Linux AArch64 systems also
have Top Byte Ignore enabled in userspace so the test "just works"
there.
FreeBSD has very recently gained Top Byte Ignore support:
4c6c27d3fb
However it's so recent, I don't want to assume it'll be available on any
random FreeBSD system out there.
There isn't really a good place to put this test, so I put it in the top
level of API, next to the other non-address bit test that didn't have a
good home either.
The `ProcessElfCore::FindModuleUUID` function can be called by multiple
threads at the same time when `target.parallel-module-load` is true. We
were using the `operator[]` to lookup the UUID which will mutate the map
when the key is not present. This is unsafe in a multi-threaded contex
so we now use a read-only `find` operation and explicitly return an
invalid UUID when the key is not present.
The `m_uuids` map can follow a create-then-query pattern. It is
populated in the `DoLoadCore` function which looks like it is only
called in a single-threaded context so we do not need extra locking as
long as we keep the other accesses read-only.
Other fixes I considered
* Use a lock to protect access - We don't need to modify the map after
creation so we can allow concurrent read-only access.
* Store the map in a const pointer container to prevent accidental
mutation in other places.
- Only accessed in one place currently so just added a comment.
* Store the UUID in the NT_FILE_Entry after building the mapping
correctly in `UpdateBuildIdForNTFileEntries`. - The map lets us avoid a
linear search in `FindModuleUUID`.
This commit also reverts the temporary workaround from #159395 which
disabled parallel module loading to avoid the test failure.
Fixes#159377
This reverts the following commits:
a0a82ee19d6f2ff1013407ba4c973bfe5428423f
757bb36a58c7d7151a28c6a5fc7caa2e1f44de87
83b48b13f3a70bf56053e92593270c519859cfd7
b45f1fb377636a34c01e34b89341c97d19975554
d2e153981e62fb2ea781ef456ff744f9893e0733
e2d1bbebbb099c7010a31fad62a9128166ef14a0
71cae12442e7476e6397fd73db05e127bfe2d035
7dd879bdc01297a551196a60bb5a5a90ca4dd1ed
f3b542e3148cfc244f63cb7c987ccf8ebc71942b
Where I had disabled specific tests due to them being flakey on our
Windows on Arm bot.
Clearly this strategy isn't working because
every day I see a new random test failing.
Until something can be done about this, disable
every lldb-dap test on Windows on Arm. The coverage we get is just not
worth spamming contributors
who have nothing to do with lldb-dap.
See #137660
Since #157170 this test has been flakey on several LLDB buildbots. I
suspect it's to do with mutli-threading, there are more details in
#159377.
Disable parallel loading for now so we are not spamming people making
unrelated changes.
This adds the ability to recognize (and create ValueObjects for) boolean
literals ("true", "false") to DIL. This is a preliminary step to adding
type casting (and also for the ternary op).
These no longer compile because the warning now defaults to an error
after #157364, so downgrade the error to a warning for now; I’m not
familiar enough with either LLDB or MacOS to fix these warnings properly
(assuming they’re unintended).
[lldb] Track CFA pointer metadata in StackID
In this commit:
9c8e71644227 [lldb] Make StackID call Fix{Code,Data} pointers (#152796)
We made StackID keep track of the CFA without any pointer metadata in
it. This is necessary when comparing two StackIDs to determine which one
is "younger".
However, the CFA inside StackIDs is also used in other contexts through
the method StackID::GetCallFrameAddress. One notable case is
DWARFExpression: the computation of `DW_OP_call_frame_address` is done
using StackID. This feeds into many other places, e.g. expression
evaluation may require the address of a variable that is computed from
the CFA; to access the variable without faulting, we may need to
preserve the pointer metadata. As such, StackID must be able to provide
both versions of the CFA.
In the spirit of allowing consumers of pointers to decide what to do
with pointer metadata, this patch changes StackID to store both versions
of the cfa pointer. Two getter methods are provided, and all call sites
except DWARFExpression preserve their existing behavior (stripped
pointer). Other alternatives were considered:
* Just store the raw pointer. This would require changing the
comparisong operator `<` to also receive a Process, as the comparison
requires stripped pointers. It wasn't clear if all call-sites had a
non-null process, whereas we know we have a process when creating a
StackID.
* Store a weak pointer to the process inside the class, and then strip
metadata as needed. This would require a `weak_ptr::lock` in many
operations of LLDB, and it felt wasteful. It also prevents stripping
of the pointer if the process has gone away.
This patch also changes RegisterContextUnwind::ReadFrameAddress, which
is the method computing the CFA fed into StackID, to also preserve the
signature pointers.
The lldb-remote-linux-ubuntu bot (and only this bot) is still failing
for TestCortexMExceptionUnwind.py because the Target triple is
somehow inheriting a non-Darwin OS. I marked this API test
skipUnlessDarwin but this bot can be identified more specifically
by a skipIfRemote test. There's no benefit to running this test
remotely anyway; it doesn't execute any code.
This patch fixes the problem, when after a `setVariable` request
pointers and references to the variable are not updated. VSCode doesn't
send a `variables` request after a `setVariable` request, so we should
trigger it explicitly via`invalidated` event .Also, updated
`writeMemory` request in similar way.
to possibly debug why this test fails on the
lldb-remote-linux-ubuntu CI bot. I'm sure the Target ArchSpec is
somehow ending up _not_ armv7m-apple-* like it should be, but I'd
like to gather a little more info before I just give up on running
this test on linux systems.
When I added support for the Cortex-M exception return unwinding,
I got CI test failures on the lldb-remote-linux-ubuntu bot. The
triple from my test `binary.json`, "armv7m-apple", was not being
used for the Target, so the incorrect SysV / AAPCS ABI was being
selected, and that ABI plugin has default unwind plans that hardcode
the arm-code r11 frame pointer behavior. This is a Cortex-M
core, and r7 should be used. The Darwin Arm ABI plugin uses r7 for
both arm and thumb, and behaves correctly.
Try getting the triple from `binary.json` in the API test, creating
the target with that triple explicitly before loading the corefile.
This may help prevent however we were losing the "-apple-" part of
the triple. We'll see what the CI bot looks like with this added.
See
https://github.com/llvm/llvm-project/pull/156803#issuecomment-3275911510
for full context.
Summary:
* In https://github.com/llvm/llvm-project/pull/156803, we see a builtbot
failure for `TestDAP_server.py` on Debian. Note that macOS and other
Linux distributions (like CentOS, or whatever Linux the [required
buildbot](https://github.com/llvm/llvm-project/actions/runs/17594257911/job/49982560193#logs)
uses) seem to pass the tests.
* In the 3 newly added tests, the most complex test case passed, while
the other easier ones failed.
```
PASS: LLDB (/home/worker/2.0.1/lldb-x86_64-debian/build/bin/clang-x86_64) :: test_connection_timeout_multiple_sessions (TestDAP_server.TestDAP_server.test_connection_timeout_multiple_sessions)
FAIL: LLDB (/home/worker/2.0.1/lldb-x86_64-debian/build/bin/clang-x86_64) :: test_connection_timeout_long_debug_session (TestDAP_server.TestDAP_server.test_connection_timeout_long_debug_session)
FAIL: LLDB (/home/worker/2.0.1/lldb-x86_64-debian/build/bin/clang-x86_64) :: test_connection_timeout_at_server_start (TestDAP_server.TestDAP_server.test_connection_timeout_at_server_start)
```
* The error is that `process.wait(timeout)` timed out during the
teardown of the tests.
* The above suggests that maybe the root cause is that the timeout is
set too strictly (and that maybe the server termination on Debian is
slower than the other Linux distribution for some reason).
* This patch loosens that timeout from 2s to 5s. Let's see if this
works.
* FWIW, I cannot verify the root cause, because I don't have a Debian
machine.
`INSERT BEFORE` keyword is not supported in current versions gold and
mold linkers. Since we cannot confirm accurately what linker and version
is available on the system and when it will be supported. We test it
with a sample program using the script keywords.
# Usage
This is an optional new command line option to use with `--connection`.
```
--connection-timeout <timeout> When using --connection, the number of seconds to
wait for new connections after the server has started and after all clients
have disconnected. Each new connection will reset the timeout. When the
timeout is reached, the server will be closed and the process will exit.
Not specifying this argument or specifying non-positive values will cause
the server to wait for new connections indefinitely.
```
A corresponding extension setting `Connection Timeout` is added to the
`lldb-dap` VS Code extension.
# Benefits
Automatic release of resources when lldb-dap is no longer being used
(e.g. release memory used by module cache).
# Test
See PR.
I'm getting a failure on one linux CI, lldb-remote-linux-ubuntu,
where the test of assertEqual(thread.GetNumFrames(), 6) fails
because the unwinder only has one frame, most likely the
target triple is not set to armv7m-apple-* so ABISysV_arm is
being used instead of ABIMacOSX_arm and the architecture default
unwind plans behave differently. Possibly the frame pointer
register, or possibly the way the arch default unwind plans are
structured.
Skipping on linux for now until I can debug further. Can repo on
Darwin by changing the binary.json `"triple": "armv7m-apple"` to
armv7m-linux.
This is something the StopInfo class manages, so it should be allowed to
compute this rather than having SBThread do so. This code just moves the
computation to methods in StopInfo. It is mostly NFC. The one change
that I actually had to adjust the tests for was a couple of tests that
were asking for the UnixSignal stop info data by asking for the data at
index 1. GetStopInfoDataCount returns 1 and we don't do 1 based indexing
so the test code was clearly wrong. But I don't think it makes sense to
perpetuate handing out the value regardless of what index you pass us.
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.
When a processor faults/is interrupted/gets an exception, it will stop
running code and jump to an exception catcher routine. Most processors
will store the pc that was executing in a system register, and the
catcher functions have special instructions to retrieve that & possibly
other registers. It may then save those values to stack, and the author
can add .cfi directives to tell lldb's unwinder where to find those
saved values.
ARM Cortex-M (microcontroller) processors have a simpler mechanism where
a fixed set of registers are saved to the stack on an exception, and a
unique value is put in the link register to indicate to the caller that
this has taken place. No special handling needs to be written into the
exception catcher, unless it wants to inspect these preserved values.
And it is possible for a general stack walker to walk the stack with no
special knowledge about what the catch function does.
This patch adds an Architecture plugin method to allow an Architecture
to override/augment the UnwindPlan that lldb would use for a stack
frame, given the contents of the return address register. It resembles a
feature where the LanguageRuntime can replace/augment the unwind plan
for a function, but it is doing it at offset by one level. The
LanguageRuntime is looking at the local register context and/or symbol
name to decide if it will override the unwind rules. For the Cortex-M
exception unwinds, we need to modify THIS frame's unwind plan if the
CALLER's LR had a specific value. RegisterContextUnwind has to retrieve
the caller's LR value before it has completely decided on the UnwindPlan
it will use for THIS stack frame.
This does mean that we will need one additional read of stack memory
than we currently do when unwinding, on Armv7 Cortex-M targets. The
unwinder walks the stack lazily, as stack frames are requested, and so
now if you ask for 2 stack frames, we will read enough stack to walk 2
frames, plus we will read one extra word of memory, the spilled LR value
from the stack. In practice, with 512-byte memory cache reads, this is
unlikely to be a real performance hit.
This PR includes a test with a yaml corefile description and a JSON
ObjectFile, incorporating all of the necessary stack memory and symbol
names from a real debug session I worked on. The architectural default
unwind plans are used for all stack frames except the 0th because
there's no instructions for the functions, and no unwind info. I may
need to add an encoding of unwind fules to ObjectFileJSON in the future
as we create more test cases like this.
This PR depends on the yaml2macho-core utility from
https://github.com/llvm/llvm-project/pull/153911 to run its API test.
rdar://110663219
This relands changes in https://github.com/llvm/llvm-project/pull/155023
for adding a count of dwo errors and combine all the dwo related stats
into one struct.
The previous PR was reverted in
https://github.com/llvm/llvm-project/pull/156777 as the newly added unit
test `test_dwo_id_mismatch_error_stats` sometimes fails due to
inappropriate use of `glob.glob`.
This change modified the tests created in the former PR to collect and
modify the dwo files by there names instead of using index after
`glob.glob`. This will avoid the possible failure in these tests if the
order of dwo files changes.
[Original PR:
https://github.com/llvm/llvm-project/pull/155023](https://github.com/llvm/llvm-project/pull/155023)
## Testing
Ran unit tests
```
$ ./bin/llvm-lit /data/users/ziyiww/llvm-project/lldb/test/API/commands/statistics/basic/TestStats.py
./bin/llvm-lit /data/users/ziyiww/llvm-project/lldb/test/API/commands/statistics/basic/TestStats.py -v
-- Testing: 1 tests, 1 workers --
PASS: lldb-api :: commands/statistics/basic/TestStats.py (1 of 1)
Testing Time: 388.52s
Total Discovered Tests: 1
Passed: 1 (100.00%)
$ bin/lldb-dotest -p TestStats.py /data/users/ziyiww/llvm-project/lldb/test/API/commands/statistics/basic/
----------------------------------------------------------------------
Ran 27 tests in 386.302s
OK (skipped=3)
```
This is failing on the lldb-aarch64-windows bots with (see error below).
XFAIL for now because it's unlikely that these expression evaluator
calls were supported before they were added.
```
======================================================================
FAIL: test_nested_no_structor_linkage_names_dwarf (TestAbiTagStructors.AbiTagStructorsTestCase.test_nested_no_structor_linkage_names_dwarf)
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 1828, in test_method
return attrvalue(self)
^^^^^^^^^^^^^^^
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\lang\cpp\abi_tag_structors\TestAbiTagStructors.py", line 108, in test_nested_no_structor_linkage_names
self.do_nested_structor_test()
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\lang\cpp\abi_tag_structors\TestAbiTagStructors.py", line 102, in do_nested_structor_test
self.expect(
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 2453, in expect
self.assertFalse(
AssertionError: True is not false : Command 'expression TaggedLocal()' is expected to fail!
Config=aarch64-C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe
======================================================================
FAIL: test_nested_with_structor_linkage_names_dwarf (TestAbiTagStructors.AbiTagStructorsTestCase.test_nested_with_structor_linkage_names_dwarf)
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 1828, in test_method
return attrvalue(self)
^^^^^^^^^^^^^^^
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\lang\cpp\abi_tag_structors\TestAbiTagStructors.py", line 112, in test_nested_with_structor_linkage_names
self.do_nested_structor_test()
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\lang\cpp\abi_tag_structors\TestAbiTagStructors.py", line 102, in do_nested_structor_test
self.expect(
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 2453, in expect
self.assertFalse(
AssertionError: True is not false : Command 'expression TaggedLocal()' is expected to fail!
Config=aarch64-C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe
======================================================================
FAIL: test_no_structor_linkage_names_dwarf (TestAbiTagStructors.AbiTagStructorsTestCase.test_no_structor_linkage_names_dwarf)
Test that without linkage names on structor declarations we can't call
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 1828, in test_method
return attrvalue(self)
^^^^^^^^^^^^^^^
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\lang\cpp\abi_tag_structors\TestAbiTagStructors.py", line 81, in test_no_structor_linkage_names
self.expect("expr Tagged t3(t1)", error=True)
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 2453, in expect
self.assertFalse(
AssertionError: True is not false : Command 'expr Tagged t3(t1)' is expected to fail!
Config=aarch64-C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe
======================================================================
FAIL: test_with_structor_linkage_names_dwarf (TestAbiTagStructors.AbiTagStructorsTestCase.test_with_structor_linkage_names_dwarf)
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 1828, in test_method
return attrvalue(self)
^^^^^^^^^^^^^^^
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\lang\cpp\abi_tag_structors\TestAbiTagStructors.py", line 20, in test_with_structor_linkage_names
self.expect_expr(
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 2596, in expect_expr
value_check.check_value(self, eval_result, str(eval_result))
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 301, in check_value
test_base.assertSuccess(val.GetError())
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 2631, in assertSuccess
self.fail(self._formatMessage(msg, "'{}' is not success".format(error)))
AssertionError: 'error: Internal error [IRForTarget]: Result variable (??__F$__lldb_expr_result@?1??$__lldb_expr@@YAXPEAX@Z@YAXXZ) is defined, but is not a global variable
```
Depends on
* https://github.com/llvm/llvm-project/pull/148877
* https://github.com/llvm/llvm-project/pull/155483
* https://github.com/llvm/llvm-project/pull/155485
* https://github.com/llvm/llvm-project/pull/154137
* https://github.com/llvm/llvm-project/pull/154142
This patch is an implementation of [this
discussion](https://discourse.llvm.org/t/rfc-lldb-handling-abi-tagged-constructors-destructors-in-expression-evaluator/82816/7)
about handling ABI-tagged structors during expression evaluation.
**Motivation**
LLDB encodes the mangled name of a `DW_TAG_subprogram` into `AsmLabel`s
on function and method Clang AST nodes. This means that when calls to
these functions get lowered into IR (when running JITted expressions),
the address resolver can locate the appropriate symbol by mangled name
(and it is guaranteed to find the symbol because we got the mangled name
from debug-info, instead of letting Clang mangle it based on AST
structure). However, we don't do this for
`CXXConstructorDecl`s/`CXXDestructorDecl`s because these structor
declarations in DWARF don't have a linkage name. This is because there
can be multiple variants of a structor, each with a distinct mangling in
the Itanium ABI. Each structor variant has its own definition
`DW_TAG_subprogram`. So LLDB doesn't know which mangled name to put into
the `AsmLabel`.
Currently this means using ABI-tagged structors in LLDB expressions
won't work (see [this
RFC](https://discourse.llvm.org/t/rfc-lldb-handling-abi-tagged-constructors-destructors-in-expression-evaluator/82816)
for concrete examples).
**Proposed Solution**
The `FunctionCallLabel` encoding that we put into `AsmLabel`s already
supports stuffing more info about a DIE into it. So this patch extends
the `FunctionCallLabel` to contain an optional discriminator (a sequence
of bytes) which the `SymbolFileDWARF` plugin interprets as the
constructor/destructor variant of that DIE. So when searching for the
definition DIE, LLDB will include the structor variant in its heuristic
for determining a match.
There's a few subtleties here:
1. At the point at which LLDB first constructs the label, it has no way
of knowing (just by looking at the debug-info declaration), which
structor variant the expression evaluator is supposed to call. That's
something that gets decided when compiling the expression. So we let the
Clang mangler inject the correct structor variant into the `AsmLabel`
during JITing. I adjusted the `AsmLabelAttr` mangling for this in
https://github.com/llvm/llvm-project/pull/155485. An option would've
been to create a new Clang attribute which behaved like an `AsmLabel`
but with these special semantics for LLDB. My main concern there is that
we'd have to adjust all the `AsmLabelAttr` checks around Clang to also
now account for this new attribute.
2. The compiler is free to omit the `C1` variant of a constructor if the
`C2` variant is sufficient. In that case it may alias `C1` to `C2`,
leaving us with only the `C2` `DW_TAG_subprogram` in the object file.
Linux is one of the platforms where this occurs. For those cases I added
a heuristic in `SymbolFileDWARF` where we pick `C2` if we asked for `C1`
but it doesn't exist. This may not always be correct (e.g., if the
compiler decided to drop `C1` for other reasons).
3. In https://github.com/llvm/llvm-project/pull/154142 Clang will emit
`C4`/`D4` variants of ctors/dtors on declarations. When resolving the
`FunctionCallLabel` we will now substitute the actual variant that Clang
told us we need to call into the mangled name. We do this using LLDB's
`ManglingSubstitutor`. That way we find the definition DIE exactly the
same way we do for regular function calls.
4. In cases where declarations and definitions live in separate modules,
the DIE ID encoded in the function call label may not be enough to find
the definition DIE in the encoded module ID. For those cases we fall
back to how LLDB used to work: look up in all images of the target. To
make sure we don't use the unified mangled name for the fallback lookup,
we change the lookup name to whatever mangled name the FunctionCallLabel
resolved to.
rdar://104968288
Due to a fallback in GDBRemoteCommunicationClient.cpp, on Linux we will
assume a PID of 1 if the remote does not respond in some way that tells
us the real PID.
So if PID 1 happened to be a process that the current user could read,
we would try to debug that instead. On my current machine, PID 1 was
sshd run by root so we would ignore it. If I changed the fallback to
some process ID run by my user, the test would fail.
To prevent this, select the remote-linux platform before creating the
target. This means we won't attempt any host lookups.
Fixes#155895
This patch loads values of the VFP registers from the NT_ARM_VFP note.
Note that a CORE/NT_FPREGSET note is typically present in core dump
files and is used to store the FPA registers. The FPA unit is rare and
obsolete; however, Linux creates the note even if the unit is absent.
The two API tests I converted to use yaml2macho-core were failing
on windows. I was writing the output corefile with fopen(filename,
"w"), and it turns out there was some newline conversion happening
on Windows if a linefeed character was present. Charles Zablit
helped to identify the issue and confirm the fix. Re-enabling the
two tests on all platforms.
https://github.com/llvm/llvm-project/pull/153911
When hitting a sanitizer breakpoint, LLDB currently displays the frame
in the sanitizer dylib (which we usually don't have debug-info for),
which isn't very helpful to the user. A more helpful frame to display
would be the first frame not in the sanitizer library (we have a
[similar heuristic when we trap inside
libc++](https://github.com/llvm/llvm-project/pull/108825)). This patch
does just that, by implementing the `GetSuggestedStackFrameIndex` API
Depends on https://github.com/llvm/llvm-project/pull/133078
Flakey on our Windows on Arm bot:
https://lab.llvm.org/buildbot/#/builders/141/builds/11378
======================================================================
ERROR: test_supported_capability_other_archs (TestDAP_stepInTargets.TestDAP_stepInTargets.test_supported_capability_other_archs)
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 2090, in tearDown
Base.tearDown(self)
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 1105, in tearDown
hook() # try the plain call and hope it works
^^^^^^
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\tools\lldb-dap\lldbdap_testcase.py", line 521, in cleanup
self.dap_server.terminate()
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\tools\lldb-dap\dap_server.py", line 1602, in terminate
raise DebugAdapterProcessError(process.returncode)
dap_server.DebugAdapterProcessError: lldb-dap returned non-zero exit status 1.
Config=aarch64-C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe
----------------------------------------------------------------------
See #137660
Flakey on our Windows on Arm bot:
https://lab.llvm.org/buildbot/#/builders/141/builds/11377
ERROR: test_step_over_inlined_function (TestDAP_step.TestDAP_step.test_step_over_inlined_function)
Test stepping over when the program counter is in another file.
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 2090, in tearDown
Base.tearDown(self)
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 1105, in tearDown
hook() # try the plain call and hope it works
^^^^^^
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\tools\lldb-dap\lldbdap_testcase.py", line 521, in cleanup
self.dap_server.terminate()
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\tools\lldb-dap\dap_server.py", line 1602, in terminate
raise DebugAdapterProcessError(process.returncode)
dap_server.DebugAdapterProcessError: lldb-dap returned non-zero exit status 1.
Config=aarch64-C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe
----------------------------------------------------------------------
See #137660.
Has been flakey on our Windows on Arm bot:
https://lab.llvm.org/buildbot/#/builders/141/builds/11373
```
======================================================================
ERROR: test_stopOnEntry (TestDAP_launch.TestDAP_launch.test_stopOnEntry)
Tests the default launch of a simple program that stops at the
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 2090, in tearDown
Base.tearDown(self)
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 1105, in tearDown
hook() # try the plain call and hope it works
^^^^^^
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\tools\lldb-dap\lldbdap_testcase.py", line 521, in cleanup
self.dap_server.terminate()
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\tools\lldb-dap\dap_server.py", line 1602, in terminate
raise DebugAdapterProcessError(process.returncode)
dap_server.DebugAdapterProcessError: lldb-dap returned non-zero exit status 1.
Config=aarch64-C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe
----------------------------------------------------------------------
```
See #137660
This came up in https://github.com/llvm/llvm-project/issues/155691.
For `std::basic_string` our formatter matching logic required the
allocator template parameter to be a `std::allocator`. There is no
compelling reason (that I know of) why this would be required for us to
apply the existing formatter to the string. We don't check the
`allocator` parameter for other STL containers either. This meant that
`std::string` that used custom allocators wouldn't be formatted. This
patch relaxes the regex for `basic_string`.
These two 32-bit macho corefile tests are still failing on the
lldb-remote-linux-win bot, I'd expect the @skipIfWindows decorator
to skip the tests there until I can debug this, but somehow because
it's a remote windows execution it's not working. Change these tests
back to skipUnlessDarwin until I can figure out whether it's
yaml2macho-core or lldb's 32-bit mach-o corefile reader support on
windows which is the problem.
I changed two tests that were previously @skipUnlessDarwin
to run on all systems, using yaml2macho-core. I'm seeing
failures on these tests on the Windows bots. I'm skipping
them on Windows for now to unblock the CI, while I try to
understand if this is a yaml2macho-core bug, or an existing
problem with lldb's macho corefile reading on windows bug.
v. https://github.com/llvm/llvm-project/pull/153911
The LLVM Style Guide says the following about error and warning messages
[1]:
> [T]o match error message styles commonly produced by other tools,
> start the first sentence with a lowercase letter, and finish the last
> sentence without a period, if it would end in one otherwise.
I often provide this feedback during code review, but we still have a
bunch of places where we have inconsistent error message, which bothers
me as a user. This PR identifies a handful of those places and updates
the messages to be consistent.
[1] https://llvm.org/docs/CodingStandards.html#error-and-warning-messages
