This reapplies commit d4020ef7c474, reverted in ac0edc55887b because it
broke build of LLDB. This commit contains appropriate changes for LLDB.
The original commit message is below.
Documentation on CreateProcessW states that maximal size of command line
is 32767 characters including ternimation null character. In the
function llvm::sys::commandLineFitsWithinSystemLimits this limit was set
to 32768. As a result if command line was exactly 32768 characters long,
a response file was not created and CreateProcessW was called with
too long command line.
Differential Revision: https://reviews.llvm.org/D83772
Summary:
On macOS 11, the libraries that have been integrated in the system
shared cache are not present on the filesystem anymore. LLDB was
using those files to get access to the symbols of those libraries.
LLDB can get the images from the target process memory though.
This has 2 consequences:
- LLDB cannot load the images before the process starts, reporting
an error if someone tries to break on a system symbol.
- Loading the symbols by downloading the data from the inferior
is super slow. It takes tens of seconds at the start of the
debug session to populate the Module list.
To fix this, we can use the library images LLDB has in its own
mapping of the shared cache. Shared cache images are somewhat
special as their LINKEDIT segment is moved to the end of the cache
and thus the images are not contiguous in memory. All of this can
hidden in ObjectFileMachO.
This patch fixes a number of test failures on macOS 11 due to the
first problem described above and adds some specific unittesting
for the new SharedCache Host utilities.
Reviewers: jasonmolenda, labath
Subscribers: llvm-commits, lldb-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D83023
With the advent of Apple Silicon, checking for the architectures
specifically is not correct anymore. This code is only supposed to
run on embedded devices (iPhones et similia), so mark it accordingly.
Since FindXcodeContentsDirectoryInPath expects the *.app/Contents and
DEVELOPER_DIR is supposed to point to Xcode.app, we need to append the
Contents path first.
Differential Revision: https://reviews.llvm.org/D81290
Summary:
This changes allows to disable or use customized libxml2 for lldb.
1. Removes redundant include_directories. The one in LLDBConfig.cmake should be enough.
2. Link to ${LIBXML2_LIBRARIES} if xml2 is enabled.
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D80257
Summary:
The comment in the Editine.h header made it sound like editline was
just unable to handle terminal resizing. We were not ever telling
editline that the terminal had changed size, which might explain why
it wasn't working.
This patch threads a `TerminalSizeChanged()` callback through the
IOHandler and invokes it from the SIGWINCH handler in the driver. Our
`Editline` class already had a `TerminalSizeChanged()` method which
was invoked only when editline was configured.
This patch also changes `Editline` to not apply the changes right away
in `TerminalSizeChanged()`, but instead defer that to the next
character read. During my testing, it happened once that the signal
was received while our `ConnectionFileDescriptor::Read` was allocating
memory. As `el_resize` seems to allocate memory too, this crashed.
Reviewers: labath, teemperor
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D79654
Summary:
The arpa/inet.h header in macOS is providing an incorrect htonl
function with enabled local submodule visibility while building LLDB. This
caused several networking tests to fail as the IP addresses are now flipped
in LLDB.
This patch disables building with modules when local submodule visibility is
active and the current system is macOS for the source/Host directory (which
is the *only directory that includes arpa/inet.h).
* debugserver also includes arpa/inet.h but there we already disabled
modules.
Reviewers: aprantl
Reviewed By: aprantl
Subscribers: mgorny, JDevlieghere
Differential Revision: https://reviews.llvm.org/D79632
When debugging a remote platform, the platform you get from
GetPlatformForArchitecture doesn't inherit from PlatformDarwin.
HostInfoMacOSX seems like the right place to have a global store of
local paths.
Differential Revision: https://reviews.llvm.org/D79364
Sadly IPv6 is still not present anywhere. The test was attempting to
detect&skip such hosts, but the way it did that (essentially, by calling
getaddrinfo) meant that it only detected hosts which have IPv6 support
completely compiled out. It did not do anything about hosts which have
it compiled in, but lack runtime configuration even for the ::1 loopback
address.
This patch changes the detection logic to use a new method. It does it
by attempting to bind a socket to the appropriate loopback address. That
should ensure the hosts loopback interface is fully set up. In an effort
to avoid silently skipping the test on too many hosts, the test is
fairly strict about the kind of error it expects in these cases -- it
will only skip the test when receiving EADDRNOTAVAIL. If we find other
error codes that can be reasonably returned in these situations, we can
add more of them.
The (small) change in TCPSocket.cpp is to ensure that the code correctly
propagates the error received from the OS.
For developing the OS itself there exists an "internal" variant of
each SDK. This patch adds support for these SDK directories to the
XcodeSDK class.
Differential Revision: https://reviews.llvm.org/D78675
This is mostly useful for Swift support; it allows LLDB to substitute
a matching SDK it shipped with instead of the sysroot path that was
used at compile time.
The goal of this is to make the Xcode SDK something that behaves more
like the compiler's resource directory, as in that it ships with LLDB
rather than with the debugged program. This important primarily for
importing Swift and Clang modules in the expression evaluator, and
getting at the APINotes from the SDK in Swift.
For a cross-debugging scenario, this means you have to have an SDK for
your target installed alongside LLDB. In Xcode this will always be the
case.
rdar://problem/60640017
Differential Revision: https://reviews.llvm.org/D76471
LLDB relies on empty FileSpecs being invalid files, for example, they
don't exists. Currently this assumption does not always hold during
reproducer replay, because we pass the result of GetPath to the VFS.
This is an empty string, which the VFS converts to an absolute directory
by prepending the current working directory, before looking it up in the
YAML mapping. This means that an empty FileSpec will exist when the
current working directory does. This breaks at least one test
(TestAddDsymCommand.py) when ran from replay.
This patch special cases empty FileSpecs and returns a sensible result
before calling GetPath and forwarding the call.
Differential revision: https://reviews.llvm.org/D77351
This patch was reverted because it introduced a failure in
TestHelloWorld.py. The reason for that was running "ls" shell command
failed as it was evaluated in an environment with an empty path. This
has now been fixed with D77123, which ensures that all shell commands
inherit the host environment, so this patch should be safe to recommit.
The original commit message was:
A defensive check in ProcessLauncherWindows meant that we would never
attempt to launch a process with a completely empty environment -- the
host environment would be used instead. Instead, I make the function add
an extra null wchar_t at the end of an empty environment. The
documentation on this is a bit fuzzy, but it seems to be what is needed
to make windows accept these kinds of environments.
Reviewers: amccarth, friss
Differential Revision: https://reviews.llvm.org/D76835
Previously, this was reverted in bf65f19b becuase it checked whether
TARGET_OS_EMBEDDED is defined, but that macro is always defined.
Update the condition to check that TARGET_OS_OSX is true.
Summary:
On most hosts we were running shell commands with an empty environment.
The only exception was windows, which was inheriting the host enviroment
mostly by accident.
Running the commands in an empty environment does not sound like a
sensible default, so this patch changes Host::RunShellCommand to inherit
the host environment. This impacts both commands run via
SBPlatform::Run (in case of host platforms), as well as the "platform
shell" CLI command.
Reviewers: jingham, friss
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77123
This reverts commit because of test failures in TestHelloWorld.
It seems that this test (specifically running "ls" as a platform shell
command) depended on the implicit passing of the host environment.
The fix should be fairly simple (inherit the environment explicitly),
but it may take me a while to figure where exactly to do that. Revert
while I am figuring that out.
Summary:
A defensive check in ProcessLauncherWindows meant that we would never
attempt to launch a process with a completely empty environment -- the
host environment would be used instead. Instead, I make the function add
an extra null wchar_t at the end of an empty environment. The
documentation on this is a bit fuzzy, but it seems to be what is needed
to make windows accept these kinds of environments.
Reviewers: amccarth, friss
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76835
Files imported by the script interpreter aren't opened by LLDB so they
don't end up in the reproducer. The solution is to explicitly add them
to the FileCollector.
Differential revision: https://reviews.llvm.org/D76626
This patch extends the reproducers to intercept calls to FindProcesses.
During capture it serializes the ProcessInstanceInfoList returned by the
API. During replay, it returns the serialized data instead of querying
the host.
The motivation for this patch is supporting the process attach workflow
during replay. Without this change it would incorrectly look for the
inferior on the host during replay and failing if no matching process
was found.
Differential revision: https://reviews.llvm.org/D75877
Summary: This is currently hidden in the Host CMakeLists but we should also use this macro in other parts of LLDB where we have ObjC++ sources (see D74891)
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D75164
LLDB has a few different styles of header guards and they're not very
consistent because things get moved around or copy/pasted. This patch
unifies the header guards across LLDB and converts everything to match
LLVM's style.
Differential revision: https://reviews.llvm.org/D74743
In 0e9b0b6d11e882efec8505d97c4b65e1562e6715 I introduced the
HistoryOperation enum to navigate the history. While this fixed the
behavior of HistoryOperation::Older and HistoryOperation::Newer, it
confused the mapping for HistoryOperation::Oldest and
HistoryOperation::Newest.
I tried to write a PExpect test to make sure this doesn't regress, but
I'm unable to prime the history in such a way that it recalls a known
element. I suspect this is an LLDB bug, but the most recent entry
doesn't get update with entries from the current session. I considered
spoofing the home directory but that needs to happen before libLLDB is
loaded and you'll need to account for the widechar support. If anyone
has another suggestion I'd love to hear it.
This breaks macOS, because TARGET_OS_EMBEDDED is always defined. Thanks
to Jason Molenda for pointing this out.
Revert "Do not define AcceptPIDFromInferior when it will not be used"
This reverts commit d23c15a687ff15327b88fa64da3184395012c2dc.
This reverts commit 936d1427da1432d724dfa5851097347bcdf7c521.
