| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 351215
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The Debuffer object was being used in "GetListenerForProcess" to provide
a default listener object if one was not specified in the launch_info
object.
Since all the callers of this function immediately passed the result to
Target::CreateProcess, it was easy to move this logic there instead.
This brings us one step closer towards being able to move the LaunchInfo
classes to the Host layer (which is there the launching code that
consumes them lives).
Reviewers: zturner, jingham, teemperor
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D56174
llvm-svn: 350510
|
|
|
|
|
|
|
|
| |
Using compare is verbose, bug prone and potentially inefficient (because
of early termination). Replace relevant call sites with the (in)equality
operator.
llvm-svn: 349972
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Simplify code path by using the FileSystem.
llvm-svn: 348232
|
|
|
|
|
|
| |
This fixes some UB in isLocal detected by the sanitized bot.
llvm-svn: 346707
|
|
|
|
|
|
| |
It broke the lldb sanitizer bots.
llvm-svn: 346694
|
|
|
|
|
|
|
|
| |
This patch removes the comments grouping header includes. They were
added after running IWYU over the LLDB codebase. However they add little
value, are often outdates and burdensome to maintain.
llvm-svn: 346626
|
|
|
|
|
|
|
|
|
|
| |
This patch removes the comments following the header includes. They were
added after running IWYU over the LLDB codebase. However they add little
value, are often outdates and burdensome to maintain.
Differential revision: https://reviews.llvm.org/D54385
llvm-svn: 346625
|
|
|
|
|
|
|
|
|
|
| |
This moves construction of data buffers into the FileSystem class. Like
some of the previous refactorings we don't translate the path yet
because the functionality hasn't been landed in LLVM yet.
Differential revision: https://reviews.llvm.org/D54272
llvm-svn: 346598
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 346283
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
This patch removes the Exists method from FileSpec and updates its uses
with calls to the FileSystem.
Differential revision: https://reviews.llvm.org/D53845
llvm-svn: 345854
|
|
|
|
|
|
|
|
|
| |
This patch removes the ResolveExecutableLocation method from FileSpec
and updates its uses with calls to the FileSystem.
Differential revision: https://reviews.llvm.org/D53834
llvm-svn: 345853
|
|
|
|
|
|
|
|
|
| |
This patch removes the GetPermissions and GetReadable methods from
FileSpec and updates its uses with calls to the FileSystem.
Differential revision: https://reviews.llvm.org/D53831
llvm-svn: 345843
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch moves the EnumerateDirectory functionality and related enum
and typedef from FileSpec to FileSystem.
This is part of a set of patches that extracts file system related
convenience methods from FileSpec. The long term goal is to remove this
method altogether and use the iterators directly, but for introducing
the VFS into LLDB this change is sufficient.
Differential revision: https://reviews.llvm.org/D53785
llvm-svn: 345800
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch extends the FileSystem class with a bunch of functions that
are currently implemented as methods of the FileSpec class. These
methods will be removed in future commits and replaced by calls to the
file system.
The new functions are operated in terms of the virtual file system which
was recently moved from clang into LLVM so it could be reused in lldb.
Because the VFS is stateful, we turned the FileSystem class into a
singleton.
Differential revision: https://reviews.llvm.org/D53532
llvm-svn: 345783
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D53709
llvm-svn: 345278
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a bug PlatformDarwin::SDKSupportsModule introduced by
https://reviews.llvm.org/D47889. VersionTuple::tryParse() can deal
with an optional third (micro) component, but the parse will fail when
there are extra characters after the version number (e.g.: trying to
parse the substring "12.0.sdk" out of "iPhoneSimulator12.0.sdk" fails
after that patch). Fixed here by stripping the ".sdk" suffix first.
(Part of) rdar://problem/45041492
Differential Revision https://reviews.llvm.org/D53677
llvm-svn: 345274
|
|
|
|
|
|
|
|
|
|
|
| |
which PlatformRemoteDarwinDevice::UpdateSDKDirectoryInfosIfNeeded
which examine for any additional SDK directories when it is
constructing its list.
<rdar://problem/42984340>
<rdar://problem/41351223>
llvm-svn: 344628
|
|
|
|
| |
llvm-svn: 344277
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LC_BUILD_VERSION load command handling - this
commit is a combination of patches by Adrian
Prantl and myself. llvm::Triple::BridgeOS
isn't defined yet, so all references to that
are currently commented out.
Also update Xcode project file to build the
NativePDB etc plugins.
<rdar://problem/43353615>
llvm-svn: 344209
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D52572
llvm-svn: 343181
|
|
|
|
| |
llvm-svn: 343134
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is an NFC commit to refactor the "load dependent files" parameter
from a boolean to an enum value. We want to be able to specify a
default, in which case we decide whether or not to load the dependent
files based on whether the target is an executable or not (i.e. a
dylib).
This is a dependency for D51934.
Differential revision: https://reviews.llvm.org/D51859
llvm-svn: 342633
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
function run.
Summary:
D48465 is currently blocked by the fact that tab-completing the first expression is deadlocking LLDB.
The reason for this deadlock is that when we push the ProcessIO handler for reading the Objective-C runtime
information from the executable (which is triggered when we parse the an expression for the first time),
the IOHandler can't be pushed as the Editline::Cancel method is deadlocking.
The deadlock in Editline is coming from the m_output_mutex, which is locked before we go into tab completion.
Even without this lock, calling Cancel on Editline will mean that Editline cleans up behind itself and deletes the
current user-input, which is screws up the console when we are tab-completing at the same time.
I think for now the most reasonable way of fixing this is to just not call Cancel on the current IOHandler when we push
the IOHandler for running an internal utility function.
As we can't really write unit tests for IOHandler itself (due to the hard dependency on an initialized Debugger including
all its global state) and Editline completion is currently also not really testable in an automatic fashion, the test for this has
to be that the expression command completion in D48465 doesn't fail when requesting completion the first time.
A more precise test plan for this is:
1. Apply D48465.
2. Start lldb and break in some function.
3. Type `expr foo` and press tab to request completion.
4. Without this patch, we deadlock and LLDB stops responding.
I'll provide an actual unit test for this once I got around and made the IOHandler code testable,
but for now unblocking D48465 is more critical.
Thanks to Jim for helping me debugging this.
Reviewers: jingham
Reviewed By: jingham
Subscribers: emaste, clayborg, abidh, lldb-commits
Differential Revision: https://reviews.llvm.org/D50912
llvm-svn: 340988
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These three classes have no external dependencies, but they are used
from various low-level APIs. Moving them down to Utility improves
overall code layering (although it still does not break any particular
dependency completely).
The XCode project will need to be updated after this change.
Differential Revision: https://reviews.llvm.org/D49740
llvm-svn: 339127
|
|
|
|
|
|
|
|
|
| |
against the OS rather than the environment. Also update other
uses of OS when we meant environment in the android local code.
NFC intended.
llvm-svn: 338460
|
|
|
|
| |
llvm-svn: 338459
|
|
|
|
|
|
| |
and we're switching on vendor and not arch.
llvm-svn: 338458
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CMake config
Summary:
LLDB_PLUGINS doesn't exist as a variable, so this line doesn't add any dependencies and is
just confusing. It seems this slipped in from the gdb-remote CMake I was using as a CMake template.
The gdb-remote CMake itself is using a local LLDB_PLUGINS variable, so that code is fine.
Reviewers: davide
Reviewed By: davide
Subscribers: davide, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D49695
llvm-svn: 337741
|
|
|
|
|
|
| |
with empty paths on it.
llvm-svn: 337515
|
|
|
|
|
|
| |
Thanks, Adrian!
llvm-svn: 336398
|
|
|
|
|
|
|
|
|
|
| |
This provides an efficient (at least on Posix platforms) way to offload to the
target process the search & loading of a library when all we have are the
library name and a set of potential candidate locations.
<rdar://problem/40905971>
llvm-svn: 335912
|
|
|
|
|
|
| |
If we have a function with signature f(addr_t, AddressClass), it is easy to muddle up the order of arguments without any warnings from compiler. 'enum class' prevents passing integer in place of AddressClass and vice versa.
llvm-svn: 335599
|
|
|
|
|
|
|
|
|
|
|
| |
passes to the recursive search function so we only recursively
search the kext bundle directory, instead of its parent directory.
<rdar://problem/41227170>
Differential Revision: https://reviews.llvm.org/D48302
llvm-svn: 335079
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Instead of a function taking an enum value determining which path to
return, we now have a suite of functions, each returning a single path
kind. This makes it easy to move the python-path function into a
specific plugin in a follow-up commit.
All the users of GetLLDBPath were converted to call specific functions
instead. Most of them were hard-coding the enum value anyway, so this
conversion was simple. The only exception was SBHostOS, which I've
changed to use a switch on the incoming enum value.
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D48272
llvm-svn: 335052
|
|
|
|
|
|
| |
This also includes one more build fix for windows.
llvm-svn: 334953
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This has multiple advantages:
- we need only one function argument/instance variable instead of three
- no need to default initialize variables
- no custom parsing code
- VersionTuple has comparison operators, which makes version comparisons much
simpler
Reviewers: zturner, friss, clayborg, jingham
Subscribers: emaste, lldb-commits
Differential Revision: https://reviews.llvm.org/D47889
llvm-svn: 334950
|
|
|
|
|
|
|
|
| |
This unbreaks the cmake build. Other plugins also use the include paths
starting with Plugins/..., so I am hoping this will work for the xcode build
too.
llvm-svn: 334697
|
|
|
|
| |
llvm-svn: 334680
|
|
|
|
| |
llvm-svn: 334667
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SetFile has an optional style argument which defaulted to the native
style. This patch makes that argument mandatory so clients of the
FileSpec class are forced to think about the correct syntax.
At the same time this introduces a (protected) convenience method to
update the file from within the FileSpec class that keeps the current
style.
These two changes together prevent a potential pitfall where the style
might be forgotten, leading to the path being updated and the style
unintentionally being changed to the host style.
llvm-svn: 334663
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With the recent changes in FileSpec to use LLVM's path style, it is
possible to delegate a bunch of common path operations to LLVM's path
helpers. This means we only have to maintain a single implementation and
at the same time can benefit from the efforts made by the rest of the
LLVM community.
This is part one of a set of patches. There was no obvious way to split
this so I just worked from top to bottom.
Differential revision: https://reviews.llvm.org/D48084
llvm-svn: 334615
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch adds a modulemap which allows compiling the lldb headers into C++ modules
(for example in builds with LLVM_ENABLE_MODULES=On).
Even though most of the affected code has been cleaned up to work with the more strict
C++ module semantics, there are still some workarounds left in the current modulemap
(the most obvious one is the big `lldb` wrapper module).
It also moves the Obj-C++ files in lldb to their own subdirectories. This was necessary
because we need to filter out the modules flags for this code.
Note: With the latest clang and libstdc++ it seems necessary to have a STL C++ module
to get a working LLVM_ENABLE_MODULES build for lldb. Otherwise clang will falsely
detect ODR violations in the textually included STL code inside the lldb modules.
Reviewers: aprantl, bruno
Reviewed By: aprantl, bruno
Subscribers: mgorny, yamaguchi, v.g.vassilev, lldb-commits
Differential Revision: https://reviews.llvm.org/D47929
llvm-svn: 334611
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This kind of functionality is useful to other project apart from clang.
LLDB works with version numbers a lot, but it does not have a convenient
abstraction for this. Moving this class to a lower level library allows
it to be freely used within LLDB.
Since this class is used in a lot of places in clang, and it used to be
in the clang namespace, it seemed appropriate to add it to the list of
adopted classes in LLVM.h to avoid prefixing all uses with "llvm::".
Also, I didn't find any tests specific for this class, so I wrote a
couple of quick ones for the more interesting bits of functionality.
Reviewers: zturner, erik.pilkington
Subscribers: mgorny, cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D47887
llvm-svn: 334399
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When loading kexts in PlatformDarwinKernel, we use the BundleID as the
filename to to create shared modules. In GetSharedModule we call
ExamineKextForMatchingUUID for any BundleID it finds that is a match, to
see if the UUID is also a match. Until now we were using
Host::ResolveExecutableInBundle which calls a CoreFoundation API to
obtain the executable. However, it's possible that the executable has a
variant suffix (e.g. foo_development) and these files were ignored.
This patch replaces that call with logic that looks for all the binaries
in the bundle. Because of the way ExamineKextForMatchingUUID works, it's
fine to try to load executables that are not valid and we can just
iterate over the list until we found a match.
Differential revision: https://reviews.llvm.org/D47539
llvm-svn: 334205
|