| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
Fixes infinite recursion due to change in how FileSpec deals with
removing the last path component.
Fixes timout for TestMiniDumpNew.py
llvm-svn: 333666
|
|
|
|
| |
llvm-svn: 333364
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The plugin already builds fine on other platforms (linux, at least). All
that was necessary was to revitalize the hack in PlatformDarwinKernel
(not a very pretty hack, but it gets us going at least).
I haven't done a thorough investigation of the state of the plugin on
other platforms, but at least the two core file tests we have seem to
pass, so I enable them.
Reviewers: JDevlieghere, jasonmolenda
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D47133
llvm-svn: 332997
|
|
|
|
|
|
|
|
| |
was failing.
This meant if the "debugserver" binary was removed from the LLDB.framework, lldb wouldn't be able to find debugserver.
llvm-svn: 332050
|
|
|
|
|
|
|
| |
this completes the Timeout migration started in r331880 with the
Predicate class.
llvm-svn: 331970
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is intended as a clean up after the big clang-format commit
(r280751), which unfortunately resulted in many of the comment
paragraphs in LLDB being very hard to read.
FYI, the script I used was:
import textwrap
import commands
import os
import sys
import re
tmp = "%s.tmp"%sys.argv[1]
out = open(tmp, "w+")
with open(sys.argv[1], "r") as f:
header = ""
text = ""
comment = re.compile(r'^( *//) ([^ ].*)$')
special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$')
for line in f:
match = comment.match(line)
if match and not special.match(match.group(2)):
# skip intentionally short comments.
if not text and len(match.group(2)) < 40:
out.write(line)
continue
if text:
text += " " + match.group(2)
else:
header = match.group(1)
text = match.group(2)
continue
if text:
filled = textwrap.wrap(text, width=(78-len(header)),
break_long_words=False)
for l in filled:
out.write(header+" "+l+'\n')
text = ""
out.write(line)
os.rename(tmp, sys.argv[1])
Differential Revision: https://reviews.llvm.org/D46144
llvm-svn: 331197
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The Args class is used in plenty of places besides the command
interpreter (e.g., anything requiring an argc+argv combo, such as when
launching a process), so it needs to be in a lower layer. Now that the
class has no external dependencies, it can be moved down to the Utility
module.
This removes the last (direct) dependency from the Host module to
Interpreter, so I remove the Interpreter module from Host's dependency
list.
Reviewers: zturner, jingham, davide
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D45480
llvm-svn: 330200
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
There was some confusion in the code about how to represent process
environment. Most of the code (ab)used the Args class for this purpose,
but some of it used a more basic StringList class instead. In either
case, the fact that the underlying abstraction did not provide primitive
operations for the typical environment operations meant that even a
simple operation like checking for an environment variable value was
several lines of code.
This patch adds a separate Environment class, which is essentialy a
llvm::StringMap<std::string> in disguise. To standard StringMap
functionality, it adds a couple of new functions, which are specific to
the environment use case:
- (most important) envp conversion for passing into execve() and likes.
Instead of trying to maintain a constantly up-to-date envp view, it
provides a function which creates a envp view on demand, with the
expectation that this will be called as the very last thing before
handing the value to the system function.
- insert(StringRef KeyEqValue) - splits KeyEqValue into (key, value)
pair and inserts it into the environment map.
- compose(value_type KeyValue) - takes a map entry and converts in back
into "KEY=VALUE" representation.
With this interface most of the environment-manipulating code becomes
one-liners. The only tricky part was maintaining compatibility in
SBLaunchInfo, which expects that the environment entries are accessible
by index and that the returned const char* is backed by the launch info
object (random access into maps is hard and the map stores the entry in
a deconstructed form, so we cannot just return a .c_str() value). To
solve this, I have the SBLaunchInfo convert the environment into the
"envp" form, and use it to answer the environment queries. Extra code is
added to make sure the envp version is always in sync.
(This also improves the layering situation as Args was in the Interpreter module
whereas Environment is in Utility.)
Reviewers: zturner, davide, jingham, clayborg
Subscribers: emaste, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D41359
llvm-svn: 322174
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We sometimes need to write to the object file we've mapped into memory,
generally to apply relocations to debug info sections. We've had that
ability before, but with the introduction of DataBufferLLVM, we have
lost it, as the underlying llvm class (MemoryBuffer) only supports
read-only mappings.
This switches DataBufferLLVM to use the new llvm::WritableMemoryBuffer
class as a back-end, as this one guarantees to return a writable buffer.
This removes the need for the "Private" flag to the DataBufferLLVM
creation functions, as it was really used to mean "writable". The LLVM
function also does not have the NullTerminate flag, so I've modified our
clients to not require this feature and removed that flag as well.
Reviewers: zturner, clayborg, jingham
Subscribers: emaste, aprantl, arichardson, krytarowski, lldb-commits
Differential Revision: https://reviews.llvm.org/D40079
llvm-svn: 321255
|
|
|
|
| |
llvm-svn: 320349
|
|
|
|
|
|
|
| |
lldb_utility doesn't make sense, as it is no longer even living in the
"utility" module.
llvm-svn: 320346
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
computer. When doing kernel debugging, lldb scrapes around a few
well-known locations to find kexts and kernels. It builds up two
lists - kexts and kernels with dSYM, and kexts and kernels without dSYMs.
After both lists have failed to provide a file, then we'll call out
to things like the DebugSymbols framework to find a kext/kernel.
This meant that when you had a kext/kernel on the local computer that
did not have debug information, lldb wouldn't consult DebugSymbols etc
once it'd locked on to one of these no-debug-info binaries on the local
computer.
Reorder this so we give DebugSymbols etc a shot at finding a debug-info
file before we use any of the no-debug-info binaries that were found on
the system.
<rdar://problem/34434440>
llvm-svn: 320241
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
most common cases where the Xcode.app bundle puts lldb -
either as a default part of the bundle, or in a toolchain
subdirectory, so the platform subclasses can find files
relative to this directory.
Dropped support for handling the case where the lldb
framework was in /Library/PrivateFrameworks. I think
this was intended to handle the case where lldb is installed
in / (outside the Xcode.app bundle) - but in that case, we
can look in the raw directory file paths to find anything.
<rdar://problem/35285622>
llvm-svn: 320240
|
|
|
|
| |
llvm-svn: 318052
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The rationale here is that ArchSpec is used throughout the codebase,
including in places which should not depend on the rest of the code in
the Core module.
This commit touches many files, but most of it is just renaming of
#include lines. In a couple of cases, I removed the #include ArchSpec
line altogether, as the file was not using it. In one or two places,
this necessitated adding other #includes like lldb-private-defines.h.
llvm-svn: 318048
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The classes have no dependencies, and they are used both by lldb and
lldb-server, so it makes sense for them to live in the lowest layers.
Reviewers: zturner, jingham
Subscribers: emaste, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D34746
llvm-svn: 306682
|
|
|
|
|
|
|
|
| |
from PlatformRemoteDarwinDevice into PlatformDarwin, and have both
PlatformRemoteDarwinDevice and PlatformMacOSX call it there.
<rdar://problem/31825940>
llvm-svn: 304520
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This renames the LLDB error class to Status, as discussed
on the lldb-dev mailing list.
A change of this magnitude cannot easily be done without
find and replace, but that has potential to catch unwanted
occurrences of common strings such as "Error". Every effort
was made to find all the obvious things such as the word "Error"
appearing in a string, etc, but it's possible there are still
some lingering occurences left around. Hopefully nothing too
serious.
llvm-svn: 302872
|
|
|
|
|
|
| |
<rdar://problem/26863256>
llvm-svn: 300810
|
|
|
|
|
|
|
|
|
| |
PlatformRemoveDarwinDevice class, subclassed to those three so they can
provide their specific information.
<rdar://problem/30159764>
llvm-svn: 300512
|
|
|
|
|
|
|
| |
This breaks the cycle between Target and PluginLanguageC++, reducing
the overall cycle count from 43 to 42.
llvm-svn: 298561
|
|
|
|
| |
llvm-svn: 298536
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D31108
llvm-svn: 298325
|
|
|
|
|
|
|
|
| |
Have callers use llvm::sys::fs::create_directory() instead.
Differential Revision: https://reviews.llvm.org/D31086
llvm-svn: 298203
|
|
|
|
|
|
|
|
|
|
| |
This was originall reverted due to some test failures in
ModuleCache and TestCompDirSymlink. These issues have all
been resolved and the code now passes all tests.
Differential Revision: https://reviews.llvm.org/D30698
llvm-svn: 297300
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
this reverts r297116 because it breaks the unittests and
TestCompDirSymlink. The ModuleCache unit test is trivially fixable, but
the CompDirSymlink failure is a symptom of a deeper problem: llvm's stat
functionality is not a drop-in replacement for lldb's. The former is
based on stat(2) (which does symlink resolution), while the latter is
based on lstat(2) (which does not).
This also reverts subsequent build fixes (r297128, r297120, 297117) and
r297119 (Remove FileSpec dependency on FileSystem) which builds on top
of this.
llvm-svn: 297139
|
|
|
|
| |
llvm-svn: 297128
|
|
|
|
|
|
|
|
|
|
| |
This deletes LLDB's FileType enumeration and replaces all
users, and all calls to functions that check whether a file
exists etc with corresponding calls to LLVM.
Differential Revision: https://reviews.llvm.org/D30624
llvm-svn: 297116
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This functionality is subsumed by DataBufferLLVM, which is
also more efficient since it will try to mmap. However, we
don't yet support mmaping writable private sections, and in
some cases we were using ReadFileContents and then modifying
the buffer. To address that I've added a flag to the
DataBufferLLVM methods that allow you to map privately, which
disables the mmaping path entirely. Eventually we should teach
DataBufferLLVM to use mmap with writable private, but that is
orthogonal to this effort.
Differential Revision: https://reviews.llvm.org/D30622
llvm-svn: 297095
|
|
|
|
| |
llvm-svn: 296943
|
|
|
|
|
|
|
|
|
| |
All references to Host and Core have been removed, so this
class can now safely be lowered into Utility.
Differential Revision: https://reviews.llvm.org/D30559
llvm-svn: 296909
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D29964
llvm-svn: 295368
|
|
|
|
| |
llvm-svn: 294221
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The std::call_once implementation in libstdc++ has problems on few systems: NetBSD, OpenBSD and Linux PPC. LLVM ships with a homegrown implementation llvm::call_once to help on these platforms.
This change is required in the NetBSD LLDB port. std::call_once with libstdc++ results with crashing the debugger.
Sponsored by <The NetBSD Foundation>
Reviewers: labath, joerg, emaste, mehdi_amini, clayborg
Reviewed By: labath, clayborg
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D29288
llvm-svn: 294202
|