This test depends on having a new packet supported by debugserver;
skip it until we have a system debugserver installed on the CI bots
with this change.
The dynamic linker on Darwin, dyld, can provide status of
the process state for a few significant points early on,
most importantly, when libSystem has been initialized and it
is safe to call functions behind the scenes. Pipe this
information up from debugserver to DynamicLoaderMacOS, for
the DynamicLoader::IsFullyInitialized() method, then have
Thread::SafeToCallFunctions use this information. Finally,
for the two utility functions in the AppleObjCRuntimeV2
LanguageRuntime plugin that I was fixing, call this method
before running our utility functions to collect the list of
objc classes registered in the runtime.
User expressions will still be allowed to run any time -
we assume the user knows what they are doing - but these
two additional utility functions that they are unaware of
will be limited by this state.
Differential Revision: https://reviews.llvm.org/D139054
rdar://102436092
can probably make function calls.
Rosetta 2 is not installed by default in a fresh macOS installation
on Apple Silicon, so x86 binaries cannot be run. CI bots are often
in this state. Update this test to check for the rosetta debugserver,
which our debugserver also hardcodes the path of, before trying to
run an x86 process on AS systems.
A fresh install of macOS does not have Rosetta 2 installed by
default; the CI bots are often in this state, resulting in a
test failure. debugserver already hardcodes the filepath of
the Rosetta 2 debugserver; test if that file exists before
running the Rosetta test.
This test requires compiling its input program without debug
information. To do so, it uses certain Makefile variables that are never
populated with custom libcxx paths (if present). Doing so would not
necessarily be correct: we cannot guarantee that said standard library
has no debug symbols.
As such, we keep using the system libraries but disable the tests in
clang versions that are too old to work with more modern system
libraries, as in the case of the lldb-matrix bot.
Differential Revision: https://reviews.llvm.org/D136178
This commit improves upon cc0b5ebf7f, which added support for
specifying which libcxx to use when testing LLDB. That patch honored
requests by tests that had `USE_LIBCPP=1` defined in their makefiles.
Now, we also use a non-default libcxx if all conditions below are true:
1. The test is not explicitly requesting the use of libstdcpp
(USE_LIBSTDCPP=1).
2. The test is not explicitly requesting the use of the system's
library (USE_SYSTEM_STDLIB=1).
3. A path to libcxx was either provided by the user through CMake flags
or libcxx was built together with LLDB.
Condition (2) is new and introduced in this patch in order to support
tests that are either:
* Cross-platform (such as API/macosx/macCatalyst and
API/tools/lldb-server). The just-built libcxx is usually not built for
platforms other than the host's.
* Cross-language (such as API/lang/objc/exceptions). In this case, the
Objective C runtime throws an exceptions that always goes through the
system's libcxx, instead of the just built libcxx. Fixing this would
require either changing the install-name of the just built libcxx in Mac
systems, or tuning the DYLD_LIBRARY_PATH variable at runtime.
Some other tests exposes limitations of LLDB when running with a debug
standard library. TestDbgInfoContentForwardLists had an assertion
removed, as it was checking for buggy LLDB behavior (which now
crashes). TestFixIts had a variable renamed, as the old name clashes
with a standard library name when debug info is present. This is a known
issue: https://github.com/llvm/llvm-project/issues/34391.
For `TestSBModule`, the way the "main" module is found was changed to
look for the "a.out" module, instead of relying on the index being 0. In
some systems, the index 0 is dyld when a custom standard library is
used.
Differential Revision: https://reviews.llvm.org/D132940
This commit improves upon cc0b5ebf7f, which added support for
specifying which libcxx to use when testing LLDB. That patch honored
requests by tests that had `USE_LIBCPP=1` defined in their makefiles.
Now, we also use a non-default libcxx if all conditions below are true:
1. The test is not explicitly requesting the use of libstdcpp
(USE_LIBSTDCPP=1).
2. The test is not explicitly requesting the use of the system's
library (USE_SYSTEM_STDLIB=1).
3. A path to libcxx was either provided by the user through CMake flags
or libcxx was built together with LLDB.
Condition (2) is new and introduced in this patch in order to support
tests that are either:
* Cross-platform (such as API/macosx/macCatalyst and
API/tools/lldb-server). The just-built libcxx is usually not built for
platforms other than the host's.
* Cross-language (such as API/lang/objc/exceptions). In this case, the
Objective C runtime throws an exceptions that always goes through the
system's libcxx, instead of the just built libcxx. Fixing this would
require either changing the install-name of the just built libcxx in Mac
systems, or tuning the DYLD_LIBRARY_PATH variable at runtime.
Some other tests exposes limitations of LLDB when running with a debug
standard library. TestDbgInfoContentForwardLists had an assertion
removed, as it was checking for buggy LLDB behavior (which now
crashes). TestFixIts had a variable renamed, as the old name clashes
with a standard library name when debug info is present. This is a known
issue: https://github.com/llvm/llvm-project/issues/34391.
For `TestSBModule`, the way the "main" module is found was changed to
look for the "a.out" module, instead of relying on the index being 0. In
some systems, the index 0 is dyld when a custom standard library is
used.
Differential Revision: https://reviews.llvm.org/D132940
This commit adds tests to ensure that queue-specific breakpoints
work as expected, as this feature wasn't being tested before.
Differential Revision: https://reviews.llvm.org/D131605
Add a function to make it easier to debug a test failure caused by an
unexpected stop reason. This is similar to the assertState helper that
was added in ce825e4674.
Before:
self.assertEqual(stop_reason, lldb.eStopReasonInstrumentation)
AssertionError: 5 != 10
After:
self.assertStopReason(stop_reason, lldb.eStopReasonInstrumentation)
AssertionError: signal (5) != instrumentation (10)
Differential revision: https://reviews.llvm.org/D131083
Add support to Mach-O corefiles and to live gdb remote serial protocol
connections for the corefile/remote stub to provide a list of load
addresses of binaries that should be found & loaded by lldb, and nothing
else. lldb will try to parse the binary out of memory, and if it can
find a UUID, try to find a binary & its debug information based on the
UUID, falling back to using the memory image if it must.
A bit of code unification from three parts of lldb that were loading
individual binaries already, so there is a shared method in
DynamicLoader to handle all of the variations they were doing.
Re-landing this with a uuid_is_null() implementation added to
Utility/UuidCompatibility.h for non-Darwin systems.
Differential Revision: https://reviews.llvm.org/D130813
rdar://94249937
rdar://94249384
This reverts commit d8879fba88.
Debian bot failure; I included <uuid/uuid.h> to get uuid_is_null() but
don't get it there. Will memcmp or whatever & recommit.
Add support to Mach-O corefiles and to live gdb remote serial protocol
connections for the corefile/remote stub to provide a list of load
addresses of binaries that should be found & loaded by lldb, and nothing
else. lldb will try to parse the binary out of memory, and if it can
find a UUID, try to find a binary & its debug information based on the
UUID, falling back to using the memory image if it must.
A bit of code unification from three parts of lldb that were loading
individual binaries already, so there is a shared method in
DynamicLoader to handle all of the variations they were doing.
Differential Revision: https://reviews.llvm.org/D130813
rdar://94249937
rdar://94249384
Xcode 14 no longer puts the Rosetta expanded shared cache in a directory
named "16.0". Instead, it includes the real version number (e.g. 13.0),
the build string and the architecture, similar to the device support
directory names for iOS, tvOS and watchOS.
Currently, when there are multiple directories, we might end up picking
the wrong one in GetSDKDirectoryForCurrentOSVersion. The problem is that
without the build string we have no way to differentiate between
multiple directories with the same version number. This patch fixes the
problem by using GetOSBuildString which, as the name implies, returns
the build string if known.
This also adds a test for Rosetta debugging on Apple Silicon. Depending
on whether the Rosetta expanded shared cache is present, the test
ensures that there is or isn't a diagnostic about reading out of memory.
rdar://97576121
Differential revision: https://reviews.llvm.org/D130540
jGetLoadedDynamicLibrariesInfos normally checks with dyld to find
the list of binaries loaded in the inferior, and getting the filepath,
before trying to parse the Mach-O binary in inferior memory.
This allows for debugserver to parse a Mach-O binary present in memory,
but not yet registered with dyld. This patch also adds some simple
sanity checks that we're reading a Mach-O header before we begin
stepping through load commands, because we won't have the sanity check
of consulting dyld for the list of loaded binaries before parsing.
Also adds a testcase.
[This patch was reverted after causing a testsuite failure on a CI bot;
I haven't been able to repro the failure outside the CI, but I have a
theory that my sanity check on cputype which only matched arm64 and
x86_64 - and the CI machine may have a watch simulator that is still
using i386.]
Differential Revision: https://reviews.llvm.org/D128956
rdar://95737734
jGetLoadedDynamicLibrariesInfos normally checks with dyld to find
the list of binaries loaded in the inferior, and getting the filepath,
before trying to parse the Mach-O binary in inferior memory.
This allows for debugserver to parse a Mach-O binary present in memory,
but not yet registered with dyld. This patch also adds some simple
sanity checks that we're reading a Mach-O header before we begin
stepping through load commands, because we won't have the sanity check
of consulting dyld for the list of loaded binaries before parsing.
Also adds a testcase.
Differential Revision: https://reviews.llvm.org/D128956
rdar://95737734
Eliminate boilerplate of having each test manually assign to `mydir` by calling
`compute_mydir` in lldbtest.py.
Differential Revision: https://reviews.llvm.org/D128077
Add a function to make it easier to debug a test failure caused by an
unexpected state.
Currently, tests are using assertEqual which results in a cryptic error
message: "AssertionError: 5 != 10". Even when a test provides a message
to make it clear why a particular state is expected, you still have to
figure out which of the two was the expected state, and what the other
value corresponds to.
We have a function in lldbutil that helps you convert the state number
into a user readable string. This patch adds a wrapper around
assertEqual specifically for comparing states and reporting better error
messages.
The aforementioned error message now looks like this: "AssertionError:
stopped (5) != exited (10)". If the user provided a message, that
continues to get printed as well.
Differential revision: https://reviews.llvm.org/D127355
I get to my work directory through a symlink, so the pathnames the
tests get for their build artifacts etc are via that symlink. There
are three tests which compare those symlink paths to a directory
received from dyld on macOS, which is the actual real pathname.
These tests have always failed for me on my dekstop but I finally
sat down to figure out why. Easy quick fix.
The previous version of this test uses mprotect, and that seemed to be
flakey on older systems. I converted the test to use the underlying
mach_vm API's. The test only runs on Darwin anyway, so this is not a
real limitation, and I'm hoping the lower level API's work more
consistently.
The test for commit bff4673b41 is failing on the
GreenDragon bot but none of us can repro the failure locally. Adding some logging
to the test failure to help diagnose the issue.
should not receive as exceptions (some will get converted to BSD
signals instead). This is really the only stable way to ensure that
a Mach exception gets converted to it's equivalent BSD signal. For
programs that rely on BSD signal handlers, this has to happen or you
can't even get the program to invoke the signal handler when under
the debugger.
This builds on a previous solution to this problem which required you
start debugserver with the -U flag. This was not very discoverable
and required lldb be the one to launch debugserver, which is not always
the case.
Differential Revision: https://reviews.llvm.org/D125434
symbol name matches. Instead, we extract the incoming path's base
name, look up all the symbols with that base name, and then compare
the rest of the context that the user provided to make sure it
matches. However, we do this comparison using just a strstr. So for
instance:
break set -n foo::bar
will match not only "a::foo::bar" but "notherfoo::bar". The former is
pretty clearly the user's intent, but I don't think the latter is, and
results in breakpoints picking up too many matches.
This change adds a Language::DemangledNameContainsPath API which can
do a language aware match against the path provided. If the language
doesn't provide this we fall back to the strstr (though that's changed
to StringRef::contains in the patch).
Differential Revision: https://reviews.llvm.org/D124579
We dropped downstream support for Python 2 in the previous release. Now
that we have branched for the next release the window where this kind of
change could introduce conflicts is closing too. Remove Python 2 checks
from the test suite.
Differential revision: https://reviews.llvm.org/D124429
Replace forms of `assertTrue(err.Success())` with `assertSuccess(err)` (added in D82759).
* `assertSuccess` prints out the error's message
* `assertSuccess` expresses explicit higher level semantics, both to the reader and for test failure output
* `assertSuccess` seems not to be well known, using it where possible will help spread knowledge
* `assertSuccess` statements are more succinct
Differential Revision: https://reviews.llvm.org/D119616
After aed965d55d we no longer demangle and store the full name. The
test was updated accordingly but the comment still specified that we
should be able to find the symbol by its full demangled name.
The symbol table needs to demangle all symbol names when building its
index. However, this doesn't require the full mangled name: we only need
the base name and the function declaration context. Currently, we always
construct the demangled string during indexing and cache it in the
string pool as a way to speed up future lookups.
Constructing the demangled string is by far the most expensive step of
the demangling process, because the output string can be exponentially
larger than the input and unless you're dumping the symbol table, many
of those demangled names will not be needed again.
This patch avoids constructing the full demangled string when we can
partially demangle. This speeds up indexing and reduces memory usage.
I gathered some numbers by attaching to Slack:
Before
------
Memory usage: 280MB
Benchmark 1: ./bin/lldb -n Slack -o quit
Time (mean ± σ): 4.829 s ± 0.518 s [User: 4.012 s, System: 0.208 s]
Range (min … max): 4.624 s … 6.294 s 10 runs
After
-----
Memory usage: 189MB
Benchmark 1: ./bin/lldb -n Slack -o quit
Time (mean ± σ): 4.182 s ± 0.025 s [User: 3.536 s, System: 0.192 s]
Range (min … max): 4.152 s … 4.233 s 10 runs
Differential revision: https://reviews.llvm.org/D118814
Version 2 of 'main bin spec' LC_NOTE allows for the specification
of a slide of where the binary is loaded in the corefile virtual
address space. It also adds a (currently unused) platform field
for the main binary.
Some corefile creators will only have a UUID and an offset to be
applied to the binary.
Changed TestFirmwareCorefiles.py to test this new form of
'main bin spec' with a slide, and also to run on both x86_64
and arm64 macOS systems.
Differential Revision: https://reviews.llvm.org/D116094
rdar://85938455
Add lldb support for a Mach-O "load binary" LC_NOTE which provides
a UUID, load address/slide, and possibly a name of a binary that
should be loaded when examining the core.
struct load_binary
{
uint32_t version; // currently 1
uuid_t uuid; // all zeroes if uuid not specified
uint64_t load_address; // virtual address where the macho is loaded, UINT64_MAX if unavail
uint64_t slide; // slide to be applied to file address to get load address, 0 if unavail
char name_cstring[]; // must be nul-byte terminated c-string, '\0' alone if name unavail
} __attribute__((packed));
Differential Revision: https://reviews.llvm.org/D115494
rdar://85069250
With arm64e ARMv8.3 pointer authentication, lldb needs to know how
many bits are used for addressing and how many are used for pointer
auth signing. This should be determined dynamically from the inferior
system / corefile, but there are some workflows where it still isn't
recorded and we fall back on a default value that is correct on some
Darwin environments.
This patch also explicitly sets the vendor of mach-o binaries to
Apple, so we select an Apple ABI instead of a random other ABI.
It adds a function pointer formatter for systems where pointer
authentication is in use, and we can strip the ptrauth bits off
of the function pointer address and get a different value that
points to an actual symbol.
Differential Revision: https://reviews.llvm.org/D115431
rdar://84644661
