Resubmission of https://reviews.llvm.org/D130309 with the 2 patches that fixed the linux buildbot, and new windows fixes.
The FileSpec APIs allow users to modify instance variables directly by getting a non const reference to the directory and filename instance variables. This makes it impossible to control all of the times the FileSpec object is modified so we can clear cached member variables like m_resolved and with an upcoming patch caching if the file is relative or absolute. This patch modifies the APIs of FileSpec so no one can modify the directory or filename instance variables directly by adding set accessors and by removing the get accessors that are non const.
Many clients were using FileSpec::GetCString(...) which returned a unique C string from a ConstString'ified version of the result of GetPath() which returned a std::string. This caused many locations to use this convenient function incorrectly and could cause many strings to be added to the constant string pool that didn't need to. Most clients were converted to using FileSpec::GetPath().c_str() when possible. Other clients were modified to use the newly renamed version of this function which returns an actualy ConstString:
ConstString FileSpec::GetPathAsConstString(bool denormalize = true) const;
This avoids the issue where people were getting an already uniqued "const char *" that came from a ConstString only to put the "const char *" back into a "ConstString" object. By returning the ConstString instead of a "const char *" clients can be more efficient with the result.
The patch:
- Removes the non const GetDirectory() and GetFilename() get accessors
- Adds set accessors to replace the above functions: SetDirectory() and SetFilename().
- Adds ClearDirectory() and ClearFilename() to replace usage of the FileSpec::GetDirectory().Clear()/FileSpec::GetFilename().Clear() call sites
- Fixed all incorrect usage of FileSpec::GetCString() to use FileSpec::GetPath().c_str() where appropriate, and updated other call sites that wanted a ConstString to use the newly returned ConstString appropriately and efficiently.
Differential Revision: https://reviews.llvm.org/D130549
The FileSpect APIs allow users to modify instance variables directly by getting a non const reference to the directory and filename instance variables. This makes it impossibly to control all of the times the FileSpec object is modified so we can clear the cache. This patch modifies the APIs of FileSpec so no one can modify the directory or filename directly by adding set accessors and by removing the get accessors that are non const.
Many clients were using FileSpec::GetCString(...) which returned a unique C string from a ConstString'ified version of the result of GetPath() which returned a std::string. This caused many locations to use this convenient function incorrectly and could cause many strings to be added to the constant string pool that didn't need to. Most clients were converted to using FileSpec::GetPath().c_str() when possible. Other clients were modified to use the newly renamed version of this function which returns an actualy ConstString:
ConstString FileSpec::GetPathAsConstString(bool denormalize = true) const;
This avoids the issue where people were getting an already uniqued "const char *" that came from a ConstString only to put the "const char *" back into a "ConstString" object. By returning the ConstString instead of a "const char *" clients can be more efficient with the result.
The patch:
- Removes the non const GetDirectory() and GetFilename() get accessors
- Adds set accessors to replace the above functions: SetDirectory() and SetFilename().
- Adds ClearDirectory() and ClearFilename() to replace usage of the FileSpec::GetDirectory().Clear()/FileSpec::GetFilename().Clear() call sites
- Fixed all incorrect usage of FileSpec::GetCString() to use FileSpec::GetPath().c_str() where appropriate, and updated other call sites that wanted a ConstString to use the newly returned ConstString appropriately and efficiently.
Differential Revision: https://reviews.llvm.org/D130309
Add a system log handler that emits log messages to the operating system
log. In addition to the log handler itself, this patch also introduces a
new Host::SystemLog helper function to abstract over writing to the
system log.
Differential revision: https://reviews.llvm.org/D128321
As it exists today, Host::SystemLog is used exclusively for error
reporting. With the introduction of diagnostic events, we have a better
way of reporting those. Instead of printing directly to stderr, these
messages now get printed to the debugger's error stream (when using the
default event handler). Alternatively, if someone is listening for these
events, they can decide how to display them, for example in the context
of an IDE such as Xcode.
This change also means we no longer write these messages to the system
log on Darwin. As far as I know, nobody is relying on this, but I think
this is something we could add to the diagnostic event mechanism.
Differential revision: https://reviews.llvm.org/D128480
This patch adds a function to check if lldb is running in an interactive
debug session. Currently this API only works on macOS. It's expected to
be used in combination with Host::OpenFileInExternalEditor.
Differential revision: https://reviews.llvm.org/D124872
Fix escaping when launching in terminal with AppleScript. The invocation
we're building up is wrapped in single quotes when passed to bash and
wrapped in double quotes for AppleScript.
Here's an example invocation with the new escaping:
tell application "Terminal"
activate
do script "/bin/bash -c 'arch -arch arm64 'darwin-debug'
--unix-socket=/tmp/dL2jSh --arch=arm64 --working-dir
\"/private/tmp/with spaces\" --disable-aslr -- \"foo\"
\"bar\" \"baz\" ; echo Process exited with status $?';exit"
end tell
Previously we were using unescaped single quotes which resulted in the
whole bash invocation being passed in pieces. That works most of the
time but breaks when you have a space in your current working directory
for example.
rdar://91870763
Differential revision: https://reviews.llvm.org/D124568
This patch removes the ability to instantiate the LLDB FileSystem class
based on a VFS overlay. This also removes the "hack" where we cast the
VFS to a RedirectingFileSystem to obtain the external path. You can
still instantiate a FileSystem with a VFS, but with the caveat that
operations that rely on the external path won't work.
Differential revision: https://reviews.llvm.org/D120923
All current callers set the argument to false. monitor_signals=true used
to be used in the Process plugins (which needed to know when the
debugged process gets a signal), but this implementation has several
serious issues, which means that individual process plugins now
orchestrate the monitoring of debugged processes themselves.
This allows us to simplify the implementation (no need to play with
process groups), and the interface (we only catch fatal events, so the
callback is always called just once).
Differential Revision: https://reviews.llvm.org/D120425
Accept a function object instead of a raw pointer. This avoids a bunch
of boilerplate typically needed to pass arguments to the thread
functions.
Differential Revision: https://reviews.llvm.org/D120321
Most of our code was including Log.h even though that is not where the
"lldb" log channel is defined (Log.h defines the generic logging
infrastructure). This worked because Log.h included Logging.h, even
though it should.
After the recent refactor, it became impossible the two files include
each other in this direction (the opposite inclusion is needed), so this
patch removes the workaround that was put in place and cleans up all
files to include the right thing. It also renames the file to LLDBLog to
better reflect its purpose.
The C headers are deprecated so as requested in D102845, this is replacing them
all with their (not deprecated) C++ equivalent.
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D103084
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
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>
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
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.
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
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 d23c15a687.
This reverts commit 936d1427da.
When launching an inferior in a new terminal window via AppleScript
and the darwin-debug helper program, we could often end up with the
inferior process having a too-high suspend count, and it would never
resume execution.
lldb tries to wait until darwin-debug has finished its work and has
launched the inferior (WaitForProcessToSIGSTOP) but this wasn't
working correctly - and cannot be made to work.
This patch removes WaitForProcessToSIGSTOP, adds a special tiny
segment to the darwin-debug executable so it can be identified as
that binary (ExecExtraSuspend), and adds code to debugserver to
detect this segment. When debugserver sees this segment, it notes
that the next exec will be done with a launch-suspended flag. When
the next exec happens, debugserver forces an extra task_resume when
we resume the inferior.
An alternative approach would be if lldb could detect when the
inferior has been launched by darwin-debug unambiguously; monitoring
when the unix socket between darwin-debug and lldb was closed would
have been a reasonable way to do this too.
<rdar://problem/29760580>
Differential Revision: https://reviews.llvm.org/D72963
Summary: There are a few places in LLDB where we do a `reinterpret_cast` for conversions that we could also do with `static_cast`. This patch moves all this code to `static_cast`.
Reviewers: shafik, JDevlieghere, labath
Reviewed By: labath
Subscribers: arphaman, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72161
Summary:
The previous attempt at making nameless process not match when searching for a
given name failed because the macos implementation was depending on this detail
in its partial matching strategy. Doing partial matching to avoid expensive
lookups is a perfectly valid thing to do, the way it was implemented seems
somewhat unexpected.
This patch implements it differently by providing special
methods in the ProcessInstanceInfoMatch which match only a subset of fields,
and changes mac host code to use those instead.
Then, it re-applies r373925 to get make the ProcessInstanceInfoMatch with a
name *not* match a nameless process.
Reviewers: JDevlieghere, teemperor, jingham
Subscribers: wallace, lldb-commits
Differential Revision: https://reviews.llvm.org/D68631
llvm-svn: 374529
This removes the CleanUp class and replaces its usages with llvm's
ScopeExit, which has similar semantics.
Differential revision: https://reviews.llvm.org/D67378
llvm-svn: 371474
This patch replaces explicit calls to log::Printf with the new LLDB_LOGF
macro. The macro is similar to LLDB_LOG but supports printf-style format
strings, instead of formatv-style format strings.
So instead of writing:
if (log)
log->Printf("%s\n", str);
You'd write:
LLDB_LOG(log, "%s\n", str);
This change was done mechanically with the command below. I replaced the
spurious if-checks with vim, since I know how to do multi-line
replacements with it.
find . -type f -name '*.cpp' -exec \
sed -i '' -E 's/log->Printf\(/LLDB_LOGF\(log, /g' "{}" +
Differential revision: https://reviews.llvm.org/D65128
llvm-svn: 366936
Change the interface to return an expected, instead of taking a Status
pointer.
Differential revision: https://reviews.llvm.org/D64163
llvm-svn: 365226
Under very specific circumstances the default shell /bin/sh might
print stuff to stderr before launching lldb-argdumper, which then
confuses the JSON parser. This patch suppresses stderr output from
lldb-argdumper to avoid this situation.
rdar://problem/50149390
Differential Revision: https://reviews.llvm.org/D61101
llvm-svn: 359156
There are set of classes in Target that describe the parameters of a
process - e.g. it's PID, name, user id, and similar. However, since it
is a bare description of a process and contains no actual functionality,
there's nothing specifically that makes this appropriate for being in
Target -- it could just as well be describing a process on the host, or
some hypothetical virtual process that doesn't even exist.
To cement this, I'm moving these classes to Utility. It's possible that
we can find a better place for it in the future, but as it is neither
Host specific nor Target specific, Utility seems like the most appropriate
place for the time being.
After this there is only 2 remaining references to Target from Host,
which I'll address in a followup.
Differential Revision: https://reviews.llvm.org/D58842
llvm-svn: 355342
Summary:
These classes describe the details of the process we are about to
launch, and so they are naturally used by the launching code in the Host
module. Previously they were present in Target because that is the most
important (but by far not the only) user of the launching code.
Since the launching code has other customers, must of which do not care
about Targets, it makes sense to move these classes to the Host layer,
next to the launching code.
This move reduces the number of times that Target is included from host
to 8 (it used to be 14).
Reviewers: zturner, clayborg, jingham, davide, teemperor
Subscribers: emaste, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D56602
llvm-svn: 353047
This patch adds the file provider which is responsible for capturing
files used by LLDB.
When capturing a reproducer, we use a file collector that is very
similar to the one used in clang. For every file that we touch, we add
an entry with a mapping from its virtual to its real path. When we
decide to generate a reproducer we copy over the files and their
permission into to reproducer folder.
When replaying a reproducer, we load the VFS mapping and instantiate a
RedirectingFileSystem. The latter will transparently use the files
available in the reproducer.
I've tested this on two macOS machines with an artificial example.
Still, it is very likely that I missed some places where we (still) use
native file system calls. I'm hoping to flesh those out while testing
with more advanced examples. However, I will fix those things in
separate patches.
Differential revision: https://reviews.llvm.org/D54617
llvm-svn: 352538
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
This patch simplifies boolean expressions acorss LLDB. It was generated
using clang-tidy with the following command:
run-clang-tidy.py -checks='-*,readability-simplify-boolean-expr' -format -fix $PWD
Differential revision: https://reviews.llvm.org/D55584
llvm-svn: 349215
Replace calls to LLVM's is_directory with calls to LLDB's FileSytem
class. For this I introduced a new convenience method that, like the
other methods, takes either a path or filespec. This still uses the LLVM
functions under the hood.
Differential revision: https://reviews.llvm.org/D54135
llvm-svn: 346375
This patch removes the logic for resolving paths out of FileSpec and
updates call sites to rely on the FileSystem class instead.
Differential revision: https://reviews.llvm.org/D53915
llvm-svn: 345890
Greg Clayton