[lldb] Replace assertEquals with assertEqual (NFC) (#82073)

assertEquals is a deprecated alias for assertEqual and has been removed
in Python 3.12. This wasn't an issue previously because we used a

[lldb] Replace assertEquals with assertEqual (NFC) (#82073)

assertEquals is a deprecated alias for assertEqual and has been removed
in Python 3.12. This wasn't an issue previously because we used a
vendored version of the unittest module. Now that we use the built-in
version this gets updated together with the Python version used to run
the test suite.

show more ...

[NFC][Py Reformat] Reformat python files in lldb

This is an ongoing series of commits that are reformatting our Python
code. Reformatting is done with `black` (23.1.0).

If you end up having problem

[NFC][Py Reformat] Reformat python files in lldb

This is an ongoing series of commits that are reformatting our Python
code. Reformatting is done with `black` (23.1.0).

If you end up having problems merging this commit because you have made
changes to a python file, the best way to handle that is to run `git
checkout --ours <yourfile>` and then reformat it with black.

RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style

Differential revision: https://reviews.llvm.org/D151460

show more ...

[lldb][tests] Automatically call compute_mydir (NFC)

Eliminate boilerplate of having each test manually assign to `mydir` by calling
`compute_mydir` in lldbtest.py.

Differential Revision: https://r

[lldb][tests] Automatically call compute_mydir (NFC)

Eliminate boilerplate of having each test manually assign to `mydir` by calling
`compute_mydir` in lldbtest.py.

Differential Revision: https://reviews.llvm.org/D128077

show more ...

[lldb] Avoid duplicate vdso modules when opening core files

When opening core files (and also in some other situations) we could end
up with two vdso modules. This could happen because the vdso modu

[lldb] Avoid duplicate vdso modules when opening core files

When opening core files (and also in some other situations) we could end
up with two vdso modules. This could happen because the vdso module is
very special, and over the years, we have accumulated various ways to
load it.

In D10800, we added one mechanism for loading it, which took the form of
a generic load-from-memory capability. Unfortunately loading an elf file
from memory is not possible (because the loader never loads the entire
file), and our attempts to do so were causing crashes. So, in D34352, we
partially reverted D10800 and implemented a custom mechanism specific to
the vdso.

Unfortunately, enough of D10800 remained such that, under the right
circumstances, it could end up loading a second (non-functional) copy of
the vdso module. This happened when the process plugin did not support
the extended MemoryRegionInfo query (added in D22219, to workaround a
different bug), which meant that the loader plugin was not able to
recognise that the linux-vdso.so.1 module (this is how the loader calls
it) is in fact the same as the [vdso] module (the name used in
/proc/$PID/maps) we loaded before. This typically happened in a core
file, as they don't store this kind of information.

This patch fixes the issue by completing the revert of D10800 -- the
memory loading code is removed completely. It also reduces the scope of
the hackaround introduced in D22219 -- it isn't completely sound and is
only relevant for fairly old (but still supported) versions of android.

I added the memory loading logic to the wasm dynamic loader, which has
since appeared and is relying on this feature (it even has a test). As
far as I can tell loading wasm modules from memory is possible and
reliable. MachO memory loading is not affected by this patch, as it uses
a completely different code path.

Since the scenarios/patches I described came without test cases, I have
created two new gdb-client tests cases for them. They're not
particularly readable, but right now, this is the best way we can
simulate the behavior (bugs) of a particular dynamic linker.

Differential Revision: https://reviews.llvm.org/D122660

show more ...

[lldb/test] Move gdb client utils into the packages tree

This infrastructure has proven proven its worth, so give it a more
prominent place.

My immediate motivation for this is the desire to reuse

[lldb/test] Move gdb client utils into the packages tree

This infrastructure has proven proven its worth, so give it a more
prominent place.

My immediate motivation for this is the desire to reuse this
infrastructure for qemu platform testing, but I believe this move makes
sense independently of that. Moving this code to the packages tree will
allow as to add more structure to the gdb client tests -- currently they
are all crammed into the same test folder as that was the only way they
could access this code.

I'm splitting the code into two parts while moving it. The first once
contains just the generic gdb protocol wrappers, while the other one
contains the unit test glue. The reason for that is that for qemu
testing, I need to run the gdb code in a separate process, so I will
only be using the first part there.

Differential Revision: https://reviews.llvm.org/D113893

show more ...

Revert "Correctly identify iOS simulator processes in debugserver."

This reverts commit 59d816d88464e93a89e0d9c80c8855ab1f453541.

It broke TestGDBRemoteClient.

Correctly identify iOS simulator processes in debugserver.

Starting with iOS 13 simulator binaries are identified with an
explicit platform in the new LC_BUILD_VERSION load command.

On older deploy

Correctly identify iOS simulator processes in debugserver.

Starting with iOS 13 simulator binaries are identified with an
explicit platform in the new LC_BUILD_VERSION load command.

On older deployment targets using the LC_VERSION_MIN load commands,
this patch detects when an ios process runs on a macOS host and
updates the target triple with the "simulator" environment
accordingly.

(Patch re-applied without modifications, the bot failure was unrelated).

This is part of https://bugs.swift.org/browse/SR-11971

rdar://problem/58438125

Differential Revision: https://reviews.llvm.org/D75696

show more ...

Revert "Correctly identify iOS simulator processes in debugserver."

This reverts commit 59d816d88464e93a89e0d9c80c8855ab1f453541.

It broke TestGDBRemoteClient.

Correctly identify iOS simulator processes in debugserver.

Starting with iOS 13 simulator binaries are identified with an
explicit platform in the new LC_BUILD_VERSION load command.

On older deploy

Correctly identify iOS simulator processes in debugserver.

Starting with iOS 13 simulator binaries are identified with an
explicit platform in the new LC_BUILD_VERSION load command.

On older deployment targets using the LC_VERSION_MIN load commands,
this patch detects when an ios process runs on a macOS host and
updates the target triple with the "simulator" environment
accordingly.

This is part of https://bugs.swift.org/browse/SR-11971

rdar://problem/58438125

Differential Revision: https://reviews.llvm.org/D75696

show more ...

[lldb][testsuite] Create a SBDebugger instance for each test

Some tests set settings and don't clean them up, this leads to side effects in other tests.
The patch removes a global debugger instance

[lldb][testsuite] Create a SBDebugger instance for each test

Some tests set settings and don't clean them up, this leads to side effects in other tests.
The patch removes a global debugger instance with a per-test debugger to avoid such effects.

From what I see, lldb.DBG was needed to determine the platform before a test is run,
lldb.selected_platform is used for this purpose now. Though, this required adding a new function
to the SBPlatform interface.

Differential Revision: https://reviews.llvm.org/D74903

show more ...

[lldb] Skip TestWasm.py on sanitized builds until D75200 has landed

[lldb] Add @skipIfXmlSupportMissing to TestWasm.py

These tests rely on being able to parse qXfer:libraries:read packet
(which is in xml).

[LLDB] Add DynamicLoaderWasmDYLD plugin for WebAssembly debugging

Add a dynamic loader plug-in class for WebAssembly modules.

Differential Revision: https://reviews.llvm.org/D72751