This patch adds a new command options to the CommandObjectProcessLaunch
for scripted processes.
Among the options, the user need to specify the class name managing the
scripted process. The user can also use a key-value dictionary holding
arbitrary data that will be passed to the managing class.
This patch also adds getters and setters to `SBLaunchInfo` for the
class name managing the scripted process and the dictionary.
rdar://65508855
Differential Review: https://reviews.llvm.org/D95710
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Our code for locating the shared library directory works via dladdr (or
the windows equivalent) to locate the path of an address known to reside
in liblldb. This works great for C++ programs, but there's a catch.
When (lib)lldb is used from python (like in our test suite), this dladdr
call will return a path to the _lldb.so (or such) file in the python
directory. To compensate for this, we have code which attempts to
resolve this symlink, to ensure we get the canonical location. However,
here's the second catch.
On windows, this file is not a symlink (but a copy), so this logic
fails. Since most of our other paths are derived from the liblldb
location, all of these paths will be wrong, when running the test suite.
One effect of this was the failure to find lldb-server in D96202.
To fix this issue, I add some windows-specific code to locate the
liblldb directory. Since it cannot rely on symlinks, it works by
manually walking the directory tree -- essentially doing the opposite of
what we do when computing the python directory.
To avoid python leaking back into the host code, I implement this with
the help of a callback which can be passed to HostInfo::Initialize in
order to assist with the directory location. The callback lives inside
the python plugin.
I also strenghten the existing path test to ensure the returned path is
the right one.
Differential Revision: https://reviews.llvm.org/D96779
Introduce a minimal support for the 32-bit powerpc platform. This
includes support for GPR and FPR registers. I also needed to add
software breakpoint opcode for PPC32/PPC64 (big endian), and to fix
offsets in RegisterInfos_powerpc.h (used only by FreeBSD register
context to be globally unique rather than relative to each struct).
Differential Revision: https://reviews.llvm.org/D95947
Honor the CPU type (and subtype) when launching the inferior on macOS.
Part of this functionality was thought to be no longer needed and
removed in 85bd436961, however it's still
needed, for example to launch binaries under Rosetta 2 on Apple Silicon.
This patch will use posix_spawnattr_setarchpref_np if available and
fallback to posix_spawnattr_setbinpref_np if not.
Differential revision: https://reviews.llvm.org/D95922
Previously file entries in the -ivfsoverlay yaml could map to a file in the
external file system, but directories had to list their contents in the form of
other file entries or directories. Allowing directory entries to map to a
directory in the external file system makes it possible to present an external
directory's contents in a different location and (in combination with the
'fallthrough' option) overlay one directory's contents on top of another.
rdar://problem/72485443
Differential Revision: https://reviews.llvm.org/D94844
As a fixme notes, both of these directory iterator implementations are
conceptually similar and duplicate the functionality of returning and uniquing
entries across two or more directories. This patch combines them into a single
class 'CombiningDirIterImpl'.
This also drops the 'Redirecting' prefix from RedirectingDirEntry and
RedirectingFileEntry to save horizontal space. There's no loss of clarity as
they already have to be prefixed with 'RedirectingFileSystem::' whenever
they're referenced anyway.
rdar://problem/72485443
Differential Revision: https://reviews.llvm.org/D94857
- s/createUniqueFile/createUniquePath -- we don't want to create the file,
just the file name
- s/data()/str().c_str()/ -- paths given to system apis must be
null-terminated
This patch adds capability to introduce a custom expedited register set
in gdb remote. Currently we send register set 0 as expedited register set
but for the case of AArch64 SVE we intend to send additional information
about SVE registers size/offset configuration which can be calculated
from vg register. Therefore we will expedited Vg register in case of
AArch64 is in SVE mode to speedup register configuration calculations.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D82853
Fix process matching by name to make 'process attach -n ...' work.
The process finding code has an optimization that defers getting
the process name and executable format after the numeric (PID, UID...)
parameters are tested. However, the ProcessInstanceInfoMatch.Matches()
method has been matching process name against the incomplete process
information as well, and effectively no process ever matched.
In order to fix this, create a copy of ProcessInstanceInfoMatch, set
it to ignore process name and se this copy for the initial match.
The same fix applies to FreeBSD and NetBSD host code.
Differential Revision: https://reviews.llvm.org/D90454
The number of resumes should always be positive to let's make this an
unsigned everywhere. Also remove the unused 'localhost' parameter from
ConvertArgumentsForLaunchingInShell.
For performance reasons the reproducers don't copy the files captured by
the file collector eagerly, but wait until the reproducer needs to be
generated.
This is a problematic when LLDB crashes and we have to do all this
signal-unsafe work in the signal handler. This patch uses a similar
trick to clang, which has the driver invoke a new cc1 instance to do all
this work out-of-process.
This patch moves the writing of the mapping file as well as copying over
the reproducers into a separate process spawned when lldb crashes.
Differential revision: https://reviews.llvm.org/D89600
Split the current NetBSD watchpoint implementation for x86 into Utility,
and revamp it to improve readability. This code is meant to be used
as a common class for all x86 watchpoint implementation, particularly
these on FreeBSD and Linux.
The code uses global watchpoint enable bits, as required by the NetBSD
kernel. If it ever becomes necessary for any platform to use local
enable bits instead, this can be trivially abstracted out.
The code also postpones clearing DR6 until a new different watchpoint
is being set in place of the old one. This is necessary since LLDB
repeatedly reenables watchpoints on all threads, by clearing
and restoring them. When DR6 is cleared as a part of that, then pending
events on other threads can no longer be associated with watchpoints
correctly.
Differential Revision: https://reviews.llvm.org/D89874
ptsname is not thread-safe. ptsname_r is available on most (but not all)
systems -- use it preferentially.
In the patch I also improve the thread-safety of the ptsname fallback
path by wrapping it in a mutex. This should guarantee the safety of a
typical ptsname implementation using a single static buffer, as long as
all callers go through this function.
I also remove the error arguments, as the only way this function can
fail is if the "primary" fd is not valid. This is a programmer error as
this requirement is documented, and all callers ensure that is the case.
Differential Revision: https://reviews.llvm.org/D88728
This changes the logic in GetXcodeSDK to find an SDK with xcrun. The
code now executes the following steps:
1. If DEVELOPER_DIR is set in the environment, it invokes xcrun with
the given developer dir. If this fails we stop and don't fall back.
2. If the shlib dir is set and exists,it invokes xcrun with the
developer dir corresponding to the shlib dir. If this fails we fall
back to 3.
3. We run xcrun without a developer dir.
The new behavior introduced in this patch is that we fall back to
running xcrun without a developer dir if running it based on the shlib
dir failed.
A situation where this matters is when you're running lldb from an Xcode
that has no SDKs and that is not xcode-selected. Based on lldb's shlib
dir pointing into this Xcode installation, it will do an xcrun with the
developer set to the Xcode without any SDKs which will fail. With this
patch, when that happens, we'll fall back to trying the xcode-selected
Xcode by running xcrun without a developer dir.
Differential revision: https://reviews.llvm.org/D88866
When compiling an Objective-C++ file, __has_feature(cxx_exceptions) will
return true with -fno-exceptions but without -fno-objc-exceptions. This
was causing LLVM_ENABLE_EXCEPTIONS to be defined for a subset of files.
The /proc/<pid>/status parsing is missing a few cases:
- Idle
- Parked
- Dead
If we encounter an unknown proc state, this leads to an msan warning. In reality, we only check that the state != Zombie, so it doesn't really matter that we handle all cases, but handle them anyway (current list: [1]). Also explicitly set it to unknown if we encounter an unknown state. There will still be an msan warning if the proc entry has no `State:` line, but that should not happen.
Use a StringSwitch to make the handling of proc states a little more compact.
[1] https://github.com/torvalds/linux/blob/master/fs/proc/array.c
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D86818
This patch adds the ability to use a custom interpreter with the
`platform shell` command. If the user set the `-s|--shell` option
with the path to a binary, lldb passes it down to the platform's
`RunShellProcess` method and set it as the shell to use in
`ProcessLaunchInfo to run commands.
Note that not all the Platforms support running shell commands with
custom interpreters (i.e. RemoteGDBServer is only expected to use the
default shell).
This patch also makes some refactoring and cleanups, like swapping
CString for StringRef when possible and updating `SBPlatformShellCommand`
with new methods and a new constructor.
rdar://67759256
Differential Revision: https://reviews.llvm.org/D86667
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Extract all the provider related logic from Reproducer.h and move it
into its own header ReproducerProvider.h. These classes are seeing most
of the development these days and this reorganization reduces
incremental compilation from ~520 to ~110 files when making changes to
the new header.
When replaying the reproducer, lldb should source the .lldbinit file
that was captured by the reproducer and not the one in the current home
directory. This requires that we store the home directory as part of the
reproducer. By returning the virtual home directory during replay, we
ensure the correct virtual path gets constructed which the VFS can then
find and remap to the correct file in the reproducer root.
This patch adds a new HomeDirectoryProvider, similar to the existing
WorkingDirectoryProvider. As the home directory is not part of the VFS,
it is stored in LLDB's FileSystem instance.
Provider a wrapper around llvm::sys::path::home_directory in the
FileSystem class. This will make it possible for the reproducers to
intercept the call in a central place.
This is relanding D81001. The patch originally failed as on newer editline
versions it seems CC_REFRESH will move the cursor to the start of the line via
\r and then back to the original position. On older editline versions like
the one used by default on macOS, CC_REFRESH doesn't move the cursor at all.
As the patch changed the way we handle tab completion (previously we did
REDISPLAY but now we're doing CC_REFRESH), this caused a few completion tests
to receive this unexpected cursor movement in the output stream.
This patch updates those tests to also accept output that contains the specific
cursor movement commands (\r and then \x1b[XC). lldbpexpect.py received an
utility method for generating the cursor movement escape sequence.
Original summary:
I implemented autosuggestion if there is one possible suggestion.
I set the keybinds for every character. When a character is typed, Editline::TypedCharacter is called.
Then, autosuggestion part is displayed in gray, and you can actually input by typing C-k.
Editline::Autosuggest is a function for finding completion, and it is like Editline::TabCommand now, but I will add more features to it.
Testing does not work well in my environment, so I can't confirm that it goes well, sorry. I am dealing with it now.
Reviewed By: teemperor, JDevlieghere, #lldb
Differential Revision: https://reviews.llvm.org/D81001
When LLDB sees only one possible completion for an input, it will add a trailing
space to the completion to signal that to the user. If the current argument is
quoted, that also means LLDB needs to add the trailing quote to finish the
current argument first.
In case the user is in a function with only one local variable and is currently
editing an empty line in the multiline expression editor, then we are in the
unique situation where we can have a unique completion for an empty input line.
(In a normal LLDB session this would never occur as empty input would just list
all the possible commands).
In this special situation our check if the current argument needs to receive a
trailing quote will crash LLDB as there is no current argument and the
completion code just unconditionally tries to access the current argument. This
just adds the missing check if we even have a current argument before we check
if we need to add a terminating quote character.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D85903
This patch configures LLDB.framework to build as a flat unversioned
framework on non-macOS Darwin targets, which have never supported the
macOS framework layout.
This patch also renames the 'IOS' cmake variable to 'APPLE_EMBEDDED' to
reflect the fact that lldb is built for several different kinds of embedded
Darwin targets, not just iOS.
Differential Revision: https://reviews.llvm.org/D85770
This reverts commit 246afe0cd1. This broke
the following tests on Linux it seems:
lldb-api :: commands/expression/multiline-completion/TestMultilineCompletion.py
lldb-api :: iohandler/completion/TestIOHandlerCompletion.py
I implemented autosuggestion if there is one possible suggestion.
I set the keybinds for every character. When a character is typed, Editline::TypedCharacter is called.
Then, autosuggestion part is displayed in gray, and you can actually input by typing C-k.
Editline::Autosuggest is a function for finding completion, and it is like Editline::TabCommand now, but I will add more features to it.
Testing does not work well in my environment, so I can't confirm that it goes well, sorry. I am dealing with it now.
Reviewed By: teemperor, JDevlieghere, #lldb
Differential Revision: https://reviews.llvm.org/D81001
No one is calling this function it seems and according to
https://bugs.llvm.org/show_bug.cgi?id=47088 this can leak memory, so let's just
remove it:
Quote from the bug report:
> Before return on line 146, the memory allocated on line 130 is not freed.
Reviewed By: amccarth
Differential Revision: https://reviews.llvm.org/D85633
Add an option that allows the user to decide to not make the inferior is
responsible for its own TCC permissions. If you don't make the inferior
responsible, it inherits the permissions of its parent. The motivation
is the scenario of running the LLDB test suite from an external hard
drive. If the inferior is responsible, every test needs to be granted
access to the external volume. When the permissions are inherited,
approval needs to be granted only once.
Differential revision: https://reviews.llvm.org/D85237
Upstream the code for dealing with TCC introduced in macOS Mojave. This
will make the debuggee instead of the debugger responsible for the
privileges it needs.
Differential revision: https://reviews.llvm.org/D85217
This reapplies commit d4020ef7c4, reverted in ac0edc5588 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
Jonas Devlieghere