For the 'thread until' command, the selected thread ID, to perform the operation on, could be of the current thread or the specified thread.
Reviewed By: jingham
Differential Revision: https://reviews.llvm.org/D48865
NativeProcessLinux is not able to properly read libraries-svr4 data when
running with ld.so as the "main" executable. Normally, this is not a big
problem, as it returns an error message, and lldb can fallback to manual
library loading.
Unfortunately, lldb-server also does not clear cached svr4 data on exec,
which means that it does *not* return an error when the application
execs from the "regular" to the "ld.so" mode. Instead it returns
incorrect data (it is missing the main executable) and causes
TestDyldExecLinux to fail (but only when building with xml support
enabled).
This patch makes ensures that cached process data is cleared on exec,
fixing the test. Since TestDyldExecLinux has shown to be sensitive to
the way we read library info, I fork it into two (with svr4 enabled and
disabled).
TCPSocket::Connect() calls SocketAddress::GetAddressInfo() and tries to
connect any of them (in a for loop).
This used to work before commit 4f6d3a376c9f("[LLDB] Fix setting of
success in Socket::Close()") https://reviews.llvm.org/D116768.
As a side effect of that commit, TCPSocket can only connect to the first
address returned by SocketAddress::GetAddressInfo().
1. If the attempt to connect to the first address fails,
TCPSocket::Connect(), calls CLOSE_SOCKET(GetNativeSocket()), which
closes the fd, but DOES NOT set m_socket to kInvalidSocketValue.
2. On the second attempt, TCPSocket::CreateSocket() calls
Socket::Close().
3. Socket::Close() proceeds, because IsValid() is true (m_socket was not
reset on step 1).
4. Socket::Close() calls ::close(m_socket), which fails
5. Since commit 4f6d3a376c9f("[LLDB] Fix setting of success in
Socket::Close()"), this is error is detected. Socket::Close() returns
an error.
6. TCPSocket::CreateSocket() therefore returns an error.
7. TCPSocket::Connect() detects the error and continues, skipping the
second (and the third, fourth...) address.
This commit fixes the problem by changing step 1: by calling
Socket::Close, instead of directly calling close(m_socket), m_socket is
also se to kInvalidSocketValue. On step 3, Socket::Close() is going to
return immediately and, on step 6, TCPSocket::CreateSocket() does not
fail.
How to reproduce this problem:
On my system, getaddrinfo() resolves "localhost" to "::1" (first) and to
"127.0.0.1" (second).
Start a gdbserver that only listens on 127.0.0.1:
```
gdbserver 127.0.0.1:2159 /bin/cat
Process /bin/cat created; pid = 2146709
Listening on port 2159
```
Start lldb and make it connect to "localhost:2159"
```
./bin/lldb
(lldb) gdb-remote localhost:2159
```
Before 4f6d3a376c9f("[LLDB] Fix setting of success in Socket::Close()"),
this used to work. After that commit, it stopped working. This commit
fixes the problem.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D126702
This patch adds a libcxx formatter for std::span. The
implementation is based on the libcxx formatter for
std::vector. The main difference is the fact that
std::span conditionally has a __size member based
on whether it has a static or dynamic extent.
Example output of formatted span:
(std::span<const int, 18446744073709551615>) $0 = size=6 {
[0] = 0
[1] = 1
[2] = 2
[3] = 3
[4] = 4
[5] = 5
}
The second template parameter here is actually std::dynamic_extent,
but the type declaration we get back from the TypeSystemClang is the
actual value (which in this case is (size_t)-1). This is consistent
with diagnostics from clang, which doesn't desugar this value either.
E.g.,:
span.cpp:30:31: error: implicit instantiation of undefined template
'Undefined<std::span<int, 18446744073709551615>>'
Testing:
Added API-tests
Confirmed manually using LLDB cli that printing spans works in various scenarios
Patch by Michael Buch!
Differential Revision: https://reviews.llvm.org/D127481
On Windows, when compile with -fdebug-compilation-dir which contains slash, the source file path in PDB will look like "../tmp\file.cc" because the path separator used is determined by target machine. Converting backslash to slash helps lldb to find the CU in ResolveSymbolContext.
We want to filter out CU with no function in ResolveSymbolContext as a cpp file will have two debug info modules in PDB if built with thinlto and one of them is a skeleton with no function debug info.
D120690 introduced `eBasicTypeChar8` but missed proper documentation order. This also introduces the missing bindings data on Swig, which should correspond with the documented information.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D116136
When using the `script` Python repl, SB objects are printed in a way that gives
the user no information. The simplest example is:
```
(lldb) script lldb.debugger
<lldb.SBDebugger; proxy of <Swig Object of type 'lldb::SBDebugger *' at 0x1097a5de0> >
```
This output comes from the Python repl printing the `repr()` of an object.
None of the SB classes implement `__repr__`, and all print like the above.
However, many (most?, all?) SB classes implement `__str__`. Because they
implement `__str__`, a more detailed output can be had by `print`ing the
object, for example:
```
(lldb) script print(lldb.debugger)
Debugger (instance: "debugger_1", id: 1)
```
For convenience, this change switches all SB classes that implement to
`__str__` to instead implement `__repr__`. **The result is that `str()` and
`repr()` will produce the same output**. This is because `str` calls `__repr__`
for classes that have no `__str__` method.
The benefit being that when writing a `script` invocation, you don't need to
remember to wrap in `print()`. If that isn't enough motivation, consider the
case where your Python expression results in a list of SB objects, in that case
you'd have to `map` or use a list comprehension like `[str(x) for x in <expr>]`
in order to see the details of the objects in the list.
For reference, the docs for `repr` say:
> repr(object)
> Return a string containing a printable representation of an object. For
> many types, this function makes an attempt to return a string that would
> yield an object with the same value when passed to eval(); otherwise, the
> representation is a string enclosed in angle brackets that contains the
> name of the type of the object together with additional information often
> including the name and address of the object. A class can control what this
> function returns for its instances by defining a __repr__() method.
and the docs for `__repr__` say:
> object.__repr__(self)
> Called by the repr() built-in function to compute the “official” string
> representation of an object. If at all possible, this should look like a
> valid Python expression that could be used to recreate an object with the
> same value (given an appropriate environment). If this is not possible, a
> string of the form <...some useful description...> should be returned. The
> return value must be a string object. If a class defines __repr__() but not
> __str__(), then __repr__() is also used when an “informal” string
> representation of instances of that class is required.
>
> This is typically used for debugging, so it is important that the
> representation is information-rich and unambiguous.
Even if it were convenient to construct Python expressions for SB classes so
that they could be `eval`'d, however for typical lldb usage, I can't think of a
motivating reason to do so. As it stands, the only action the docs say to do,
that this change doesn't do, is wrap the `repr` string in `<>` angle brackets.
An alternative implementation is to change lldb's python repl to apply `str()`
to the top level result. While this would work well in the case of a single SB
object, it doesn't work for a list of SB objects, since `str([x])` uses `repr`
to convert each list element to a string.
Differential Revision: https://reviews.llvm.org/D127458
This patch changes the `crashlog` command behavior to print the help
message if no argument was provided with the command.
rdar://94576026
Differential Revision: https://reviews.llvm.org/D127362
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Tested by building the docs-lldb-html target and
confirming the code-block renders properly with
the fix.
Patch by Michael Buch!
Differential Revision: https://reviews.llvm.org/D127437
PE/COFF can use either MSVC or GNU (MinGW) ABI for C++ code, however
LLDB had defaulted to MSVC implicitly with no way to override it. This
causes issues when debugging modules built with the GNU ABI, sometimes
even crashes.
This changes the PE/COFF plugin to set the module triple according to
the default target triple used to build LLDB. If the default target
triple is Windows and a valid environment is specified, then this
environment will be used for the module spec. This not only works for
MSVC and GNU, but also other environments.
A new setting, `plugin.object-file.pe-coff.abi`, has been added to
allow overriding this default ABI.
* Fixes https://github.com/llvm/llvm-project/issues/50775
* Fixes https://github.com/mstorsjo/llvm-mingw/issues/226
* Fixes https://github.com/mstorsjo/llvm-mingw/issues/282
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D127048
Include a reference to the documentation for "on demand symbols" in the
documentation index. This will ensure the page shows up in the side bar
on the website.
The specification of gnu-debuglink can be found at:
https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html
The file CRC or the CRC value from the .gnu_debuglink section is now
used to calculate the module UUID as a fallback, to allow verifying that
the debug object does match the executable. Note that if a CodeView
build id exists, it still takes precedence. This works even for MinGW
builds because LLD writes a synthetic CodeView build id which does not
get stripped from the debug object.
The `Minidump/Windows/find-module` test also needs a fix by adding a
CodeView record to the exe to match the one in the minidump, otherwise
it fails due to the new UUID calculated from the file CRC.
Fixes https://github.com/llvm/llvm-project/issues/54344
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D126367
1. If array element type is a tag decl, complete it.
2. Fix few places where `asTag` should be used instead of `asClass()`.
3. Handle the case that `PdbAstBuilder::CreateFunctionDecl` return nullptr mainly due to an existing workaround (`m_cxx_record_map`).
4. `FindMembersSize` should never return error as this would cause early exiting in `CVTypeVisitor::visitFieldListMemberStream` and then cause assertion failure.
5. In some pdbs from C++ runtime libraries have S_LPROC32 followed directly by S_LOCAL and the local variable location is a S_DEFRANGE_FRAMEPOINTER_REL. There is no information about base frame register in this case, ignoring it by returning RegisterId::NONE.
6. Add a TODO when S_DEFRANGE_SUBFIELD_REGISTER describes the variable location of a pointer type. For now, just ignoring it if the variable is pointer.
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
On macOS Ventura and later, dyld and the main binary will be loaded
again when dyld moves itself into the shared cache. Update the test
accordingly.
Differential revision: https://reviews.llvm.org/D127331
Adds a check to ensure that a process exists before attempting to get
its ABI to prevent lldb from crashing due to trying to read from page zero.
Differential revision: https://reviews.llvm.org/D127016
In order to avoid stranding the Objective-C runtime lock, we switched
from objc_copyRealizedClassList to its non locking variant
objc_copyRealizedClassList_nolock. Not taking the lock was relatively
safe because we run this expression on one thread only, but it was still
possible that someone was in the middle of modifying this list while we
were trying to read it. Worst case that would result in a crash in the
inferior without side-effects and we'd unwind and try again later.
With the introduction of macOS Ventura, we can use
objc_getRealizedClassList_trylock instead. It has semantics similar to
objc_copyRealizedClassList_nolock, but instead of not locking at all,
the function returns if the lock is already taken, which avoids the
aforementioned crash without stranding the Objective-C runtime lock.
Because LLDB gets to allocate the underlying memory we also avoid
stranding the malloc lock.
rdar://89373233
Differential revision: https://reviews.llvm.org/D127252
A non-zero exit code from the test binary results in a
CalledProcessError. Without catching the exception, that would result in
a error (unresolved test) instead of a failure. This patch fixes that.
Currently we look for keywords in the dotest.py output to determine the
lit result code. This binary approach of a keyword being present works
for PASS and FAIL, where having at least one test pass or fail
respectively results in that exit code. Things are more complicated
for tests that neither passed or failed, but report a combination of
(un)expected failures, skips or unresolved tests.
This patch changes the logic to parse the number of tests with a
particular result from the dotest.py output. For tests that did not PASS
or FAIL, we now report the lit result code for the one that occurred the
most. For example, if we had a test with 3 skips and 4 expected
failures, we report the test as XFAIL.
We're still mapping multiple tests to one result code, so some loss of
information is inevitable.
Differential revision: https://reviews.llvm.org/D127258
This test depends on multiple threads with one of them
hitting a watchpoint at the same time as a breakpoint, and
can fail because of the way arm64 watchpoints are handled.
I added skips to most of these via
```
commit bef4da4a6a
Author: Jason Molenda <jason@molenda.com>
Date: Wed May 25 16:05:16 2022 -0700
Skip testing of watchpoint hit-count/ignore-count on multithreaded
```
but missed that this test is susceptable to the same issue.
On macOS, a process will be launched with /usr/lib/dyld (the
dynamic linker) and the main binary by the kernel. The
first thing the standalone dyld will do is call into the dyld
in the shared cache image. This patch tracks the transition
between the dyld's at the very beginning of process startup.
In DynamicLoaderMacOS::NotifyBreakpointHit() there are two new
cases handled:
`dyld_image_dyld_moved` which is the launch /usr/lib/dyld indicating
that it is about call into the shared cache dyld ane evict itself.
lldb will remove the notification breakpoint it set, clear the binary
image list entirely, get the notification function pointer value out
of the dyld_all_image_infos struct (which is the notification fptr
in the to-be-run shared-cache dyld) and put an address breakpoint
there.
`dyld_notify_adding` is then called by shared-cache dyld, and we
detect this case by noticing that we have an empty binary image list,
normally impossibe, and treating this as if we'd just started a
process attach/launch.
Differential Revision: https://reviews.llvm.org/D127247
rdar://84222158
There are 3 places where we were using WASM_SEC_TAG as the "last" known
section type, which requires updating (or leaves a bug) when a new known
section type is added. Instead add a "last type" to the enum for this
purpose.
Differential Revision: https://reviews.llvm.org/D127164
This patch remove XFAIL decorator from tests which as passing on AArch64
Windows. This is tested on surface pro x using tot llvm and clang 14.0.3
as compiler with visual studio 2019 x86_arm64 environment.
This patch adds a minor fix in lldbtest.py TestBase.generateSource
function. Generated Python source with directory paths was not being
escaped properly. This fix makes sure we treat dir path as raw string.
This patch removes use of -fno-builtin flag for building LLDB API
tests.
LLDB API tests are built using Makefile.rules where we were using
-fno-builtin flag to avoid gcc intrinsic optimization conflicting
with Android runtime in past.
Now that we no longer use gcc for building testsuite and compiling
LLDB API tests on AArch64/Windows require clang to optimize certain
calls like _setjmp to setjmpex as former is not implemented by
AArch64 windows runtime.
It was putting the command the user typed, and then the resolved command in the
command history. That caused up-arrow not to work correctly when the regex command
was invoked from a Python-command. Plus it's just weird.
Differential Revision: https://reviews.llvm.org/D126789
Do not send SIGSTOP when requested to halt a process that's already
stopped. This results in the signal being queued for delivery once
the process is resumed, and unexpectedly stopping it again.
This is necessary for non-stop protocol patches to land.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D126770
This patch renames DW_ACCESS_to_AccessType function and move it to the abstract
DWARFASTParser, since there is no clang-specific code there. This is useful for
plugins other than Clang.
Reviewed By: shafik, bulbazord
Differential Revision: https://reviews.llvm.org/D114719
This patch moves ParseChildArrayInfo out of DWARFASTParserClang in order
to decouple Clang-specific logic from DWARFASTParser.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D114668
Signed-off-by: Luís Ferreira <contact@lsferreira.net>
The function that was supposed to iterate over all the breakpoints sharing
BKPT_NAME stopped after the first one because of a reversed "if success"
condition.
Differential Revision: https://reviews.llvm.org/D126730
lldb will only backtrace a fixed number of stack frames, as a
last-ditch attempt to avoid a runaway looping backtrace. It's
unusual that anyone ends up depending on this final safety net in
years. I picked the original number of 300000 was picked by seeing
how many stack frames I could make in a small recursive function
on Darwin systems before using the default stack space. Checking
again today on a modern system, I can exceed this limit & lldb will
not show the original invocation of the recursing call. Double the
old value to cover this larger maximum possible stack frame count,
as a default value.
(`target.process.thread.max-backtrace-depth`)
When cross compiling, a separate nested cmake is spawned, for building
host code generation tools such as lldb-tblgen.
When cross compiling on macOS, the nested native build would trigger
the lldb check for libc++, if testing is enabled (which it is by default).
(Even if `LLDB_INCLUDE_TESTS=OFF` is set on the main build, it has to
be passed separately in `CROSS_TOOLCHAIN_FLAGS_NATIVE` to reach the
nested build.)
Skip this check when building the host tools when cross compiling, as
the user won't try to run tests in that nested build.
(Alternatively, we could consider disabling all the `*_INCLUDE_TESTS`
by default in the nested host tools build.)
Differential Revision: https://reviews.llvm.org/D126557
Venkata Ramanaiah Nalamothu