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
Summary:
This adds unnamed pipe support in PipeWindows to support communication between a debug server and child process.
Modify PipeWindows::CreateNew to support the creation of an unnamed pipe.
Rename the previous method that created a named pipe to PipeWindows::CreateNewNamed.
Reviewers: zturner, llvm-commits
Reviewed By: zturner
Subscribers: Hui, labath, lldb-commits
Differential Revision: https://reviews.llvm.org/D56234
llvm-svn: 350784
Summary:
Add features to LLDB CMake builds that have so far only been available in Xcode. Clean up a few inconveniences and prepare further improvements.
Options:
* `LLDB_FRAMEWORK_BUILD_DIR` determines target directory (in build-tree)
* `LLDB_FRAMEWORK_INSTALL_DIR` **only** determines target directory in install-tree
* `LLVM_EXTERNALIZE_DEBUGINFO` allows externalized debug info (dSYM on Darwin, emitted to `bin`)
* `LLDB_FRAMEWORK_TOOLS` determines which executables will be copied to the framework's Resources (dropped symlinking, removed INCLUDE_IN_SUITE, removed dummy targets)
Other changes:
* clean up `add_lldb_executable()`
* include `LLDBFramework.cmake` from `source/API/CMakeLists.txt`
* use `*.plist.in` files, which are typical for CMake and independent from Xcode
* add clang headers to the framework bundle
Reviewers: xiaobai, JDevlieghere, aprantl, davide, beanz, stella.stamenova, clayborg, labath
Reviewed By: aprantl
Subscribers: friss, mgorny, lldb-commits, #lldb
Differential Revision: https://reviews.llvm.org/D55328
llvm-svn: 350391
This patch changes the way the reproducer is initialized. Rather than
making changes at run time we now do everything at initialization time.
To make this happen we had to introduce initializer options and their SB
variant. This allows us to tell the initializer that we're running in
reproducer capture/replay mode.
Because of this change we also had to alter our testing strategy. We
cannot reinitialize LLDB when using the dotest infrastructure. Instead
we use lit and invoke two instances of the driver.
Another consequence is that we can no longer enable capture or replay
through commands. This was bound to go away form the beginning, but I
had something in mind where you could enable/disable specific providers.
However this seems like it adds very little value right now so the
corresponding commands were removed.
Finally this change also means you now have to control this through the
driver, for which I replaced --reproducer with --capture and --replay to
differentiate between the two modes.
Differential revision: https://reviews.llvm.org/D55038
llvm-svn: 348152
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 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
We used to have a pretty stack trace printer in SystemInitializerCommon.
This was disabled on Apple because we didn't want the library to be
setting signal handlers, as this was causing issues when loaded into
Xcode. However, I think it's useful to have this for the LLDB driver, so
I moved it up to use the PrettyStackTraceProgram in the driver's main.
Differential revision: https://reviews.llvm.org/D49377
llvm-svn: 337261
Summary:
In this patch I aim to do the following:
1) Create an lldb-framework target that acts as the target that handles generating LLDB.framework. Previously, liblldb acted as the target for generating the framework in addition to generating the actual lldb library. This made the target feel overloaded.
2) Centralize framework generation as much as it makes sense to do so.
3) Create a target lldb-suite, which depends on every tool and library that makes liblldb fully functional. One result of having this target is it makes tracking dependencies much clearer.
Differential Revision: https://reviews.llvm.org/D48060
llvm-svn: 334968
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
Summary:
For lldb-server, it is sufficient to parse only the native object file
format for its target OS (no other file can be loaded into a running
process). This moves the object file initialization code into specific
initializer classes: lldb-test and liblldb get all object files;
lldb-server gets only one of them. For this to work, I've needed to
create a special SystemInitializer for use in lldb-server, instead of it
calling directly into the common one.
This reduces the size of lldb-server by about 2%, which is not
earth-shattering, but it's an easy win, and it helps.
Reviewers: zturner, clayborg
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D47250
llvm-svn: 333182
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 were failing to propagate the environment when lldb-server was
started with a pre-loaded process
(e.g.: lldb-server gdbserver -- inferior --inferior_args)
This patch makes sure the environment is propagated. Instead of adding a
new GDBRemoteCommunicationServerLLGS::SetLaunchEnvironment function to
complement SetLaunchArgs and SetLaunchFlags, I replace these with a
more generic SetLaunchInfo, which can be used to set any launch-related
property.
The accompanying test also verifies that the server correctly terminates
the connection after sending the exit packet (specifically, that it does
not send the exit packet twice).
Reviewers: clayborg, eugene
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D41070
llvm-svn: 320984
This is a follow-up to r319840. I guess none of the systems I'd tested
on before had LLDB_SYSTEM_LIBS set, which is why I didn't see any local
errors, but I'm surprised none of the bots caught it either.
llvm-svn: 319953
Summary:
r316368 broke this build when it introduced a reference to a pthread
function to the Utility module. This caused cmake to generate an
incorrect link line (wrong order of libs) because it did not see the
dependency from Utility to the system libraries. Instead these libraries
were being manually added to each final target.
This changes moves the dependency management from the individual targets
to the lldbUtility module, which is consistent with how llvm does it.
The final targets will pick up these libraries as they will be a part of
the link interface of the module.
Technically, some of these dependencies could go into the host module,
as that's where most of the os-specific code is, but I did not try to
investigate which ones.
Reviewers: zturner, sylvestre.ledru
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D39246
llvm-svn: 316997
Using TCP sockets is insecure against local attackers, and possibly
against remote attackers too (some vulnerabilities may allow tricking a
browser to make a request to localhost). Use socketpair (which is immune
to such attacks) on all Unix platforms.
Patch by Demi Marie Obenour < demiobenour@gmail.com >
Differential Revision: https://reviews.llvm.org/D33213
llvm-svn: 314127
Summary:
The usage of shared_from_this forces us to separate construction and
initialization phases, because shared_from_this() is not available in
the constructor (or destructor). The shared semantics are not necessary,
as we always have a clear owner of the native process class
(GDBRemoteCommunicationServerLLDB object). Even if we need shared
semantics in the future (which I think we should strongly avoid),
reverting this will not be necessary -- the owners can still easily
store the native process object in a shared pointer if they really want
to -- this just prevents the knowledge of that from leaking into the
class implementation.
After this a NativeThread object will hold a reference to the parent
process (instead of a weak_ptr) -- having a process instance always
available allows us to simplify some logic in this class (some of it was
already simplified because we were asserting that the process is
available, but this makes it obvious).
Reviewers: krytarowski, eugene, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D35123
llvm-svn: 308282
Summary:
This replaces the static functions used for creating
NativeProcessProtocol instances with a factory pattern, and modernizes
the interface of the new class in the process -- I use llvm::Expected
instead of the Status+value combo. I also move some of the common code
(like the Delegate registration into the base class). The new
arrangement has multiple benefits:
- it removes the NativeProcess*** dependency from Process/gdb-remote
(which for example means that liblldb no longer pulls in this code).
- it enables unit testing of the GDBRemoteCommunicationServerLLGS class
(by providing a mock Native Process).
- serves as another example on how to use the llvm::Expected class (I
couldn't get rid of the Initialize-type functions completely here
because of the use of shared_from_this, but that's the next thing on
my list here)
Tests still pass on Linux and I've made sure NetBSD compiles after this.
Reviewers: zturner, eugene, krytarowski
Subscribers: srhines, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D33778
llvm-svn: 307390
Summary:
These interfaces have no dependencies, so it makes sense for them to be
in the lowest level modules, to make sure that other parts of the
codebase can use them without introducing loops.
The only exception here is the Connection::CreateDefaultConnection
method, which I've moved to Host, as it instantiates concrete
implementations, and that's where the implementations live.
Reviewers: jingham, zturner
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D34400
llvm-svn: 306391
strerror is not thread-safe. llvm's StrError tries hard to retrieve the
string in a thread-safe way and falls back to strerror only if it does
not have another way.
llvm-svn: 304795
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
This support was landed in r300579, and reverted in r300669 due to failures on the bots.
The failures were caused by sockets not being properly closed, and this updated version of the patches should resolve that.
Summary from the original change:
This patch adds IPv6 support to LLDB/Host's TCP socket implementation. Supporting IPv6 involved a few significant changes to the implementation of the socket layers, and I have performed some significant code cleanup along the way.
This patch changes the Socket constructors for all types of sockets to not create sockets until first use. This is required for IPv6 support because the socket type will vary based on the address you are connecting to. This also has the benefit of removing code that could have errors from the Socket subclass constructors (which seems like a win to me).
The patch also slightly changes the API and behaviors of the Listen/Accept pattern. Previously both Listen and Accept calls took an address specified as a string. Now only listen does. This change was made because the Listen call can result in opening more than one socket. In order to support listening for both IPv4 and IPv6 connections we need to open one AF_INET socket and one AF_INET6 socket. During the listen call we construct a map of file descriptors to addrin structures which represent the allowable incoming connection address. This map removes the need for taking an address into the Accept call.
This does have a change in functionality. Previously you could Listen for connections based on one address, and Accept connections from a different address. This is no longer supported. I could not find anywhere in LLDB where we actually used the APIs in that way. The new API does still support AnyAddr for allowing incoming connections from any address.
The Listen implementation is implemented using kqueue on FreeBSD and Darwin, WSAPoll on Windows and poll(2) everywhere else.
https://reviews.llvm.org/D31823
llvm-svn: 301492
The break the linux bots (and probably any other machine which would
run the test suite in a massively parallel way). The problem is that it
can happen that we only successfully create an IPv6 listening socket
(because the relevant IPv4 port is used by another process) and then the
connecting side attempts to connect to the IPv4 port and fails.
It's not very obvious how to fix this problem, so I am reverting this
until we come up with a solution.
llvm-svn: 300669
Summary:
This patch adds IPv6 support to LLDB/Host's TCP socket implementation. Supporting IPv6 involved a few significant changes to the implementation of the socket layers, and I have performed some significant code cleanup along the way.
This patch changes the Socket constructors for all types of sockets to not create sockets until first use. This is required for IPv6 support because the socket type will vary based on the address you are connecting to. This also has the benefit of removing code that could have errors from the Socket subclass constructors (which seems like a win to me).
The patch also slightly changes the API and behaviors of the Listen/Accept pattern. Previously both Listen and Accept calls took an address specified as a string. Now only listen does. This change was made because the Listen call can result in opening more than one socket. In order to support listening for both IPv4 and IPv6 connections we need to open one AF_INET socket and one AF_INET6 socket. During the listen call we construct a map of file descriptors to addrin structures which represent the allowable incoming connection address. This map removes the need for taking an address into the Accept call.
This does have a change in functionality. Previously you could Listen for connections based on one address, and Accept connections from a different address. This is no longer supported. I could not find anywhere in LLDB where we actually used the APIs in that way. The new API does still support AnyAddr for allowing incoming connections from any address.
The Listen implementation is implemented using kqueue on FreeBSD and Darwin, WSAPoll on Windows and poll(2) everywhere else.
Reviewers: zturner, clayborg
Subscribers: jasonmolenda, labath, lldb-commits, emaste
Differential Revision: https://reviews.llvm.org/D31823
llvm-svn: 300579
Summary:
This is the base for introduction of further features to support Process Tracing on NetBSD, in local and remote setup.
This code is also a starting point to synchronize the development with other BSDs. Currently NetBSD is ahead and other systems can catch up.
Sponsored by <The NetBSD Foundation>
Reviewers: emaste, joerg, kettenis, labath
Reviewed By: labath
Subscribers: mgorny, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D31138
llvm-svn: 298408
Summary:
ofstream does not handle paths with non-ascii characters correctly on
windows, so I am switching these to llvm streams to fix that.
Reviewers: zturner, eugene
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D31079
llvm-svn: 298375
Summary:
previously we switched to llvm streams for log output, this completes
the switch for the error streams.
I also clean up the includes and remove the unused argument from
DisableAllLogChannels().
This required adding a bit of boiler plate to convert the output in the
command interpreter, but that should go away when we switch command
results to use llvm streams as well.
Reviewers: zturner, eugene
Subscribers: lldb-commits, emaste
Differential Revision: https://reviews.llvm.org/D30894
llvm-svn: 297812
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
Summary:
Use StringRef and ArrayRef where possible. This adds an accessor to the
Args class to get a view of the arguments as ArrayRef<const char *>.
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30402
llvm-svn: 296592
Summary:
This converts LLDB's logging to use llvm streams instead of
lldb_private::Stream and friends. The changes are mostly
straight-forward and amount to s/lldb_private::Stream/llvm::raw_ostream.
The part worth calling out is the rewrite of the StreamCallback class.
Previously this class contained a per-thread buffer of data written. I
assume this had something to do with it trying to make sure each log
line is delivered as a single event, instead of multiple (possibly
interleaved) events. However, this is no longer relevant as the Log
class already writes things to a temporary buffer and then delivers the
message as a single "write", so I have just removed the code in
question.
Reviewers: zturner, clayborg
Subscribers: emaste, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D29615
llvm-svn: 294736
Summary:
This patch removes the over-specified dependencies from LLDBDependencies and instead relies on the dependencies as expressed in each library and tool.
This also removes the library looping in favor of allowing CMake to do its thing. I've tested this patch on Darwin, and found no issues, but since linker semantics vary by system I'll also work on testing it on other platforms too.
Help testing would be greatly appreciated.
Reviewers: labath, zturner
Subscribers: danalbert, srhines, mgorny, jgosnell, lldb-commits
Differential Revision: https://reviews.llvm.org/D29352
llvm-svn: 294515
This moves the following classes from Core -> Utility.
ConstString
Error
RegularExpression
Stream
StreamString
The goal here is to get lldbUtility into a state where it has
no dependendencies except on itself and LLVM, so it can be the
starting point at which to start untangling LLDB's dependencies.
These are all low level and very widely used classes, and
previously lldbUtility had dependencies up to lldbCore in order
to use these classes. So moving then down to lldbUtility makes
sense from both the short term and long term perspective in
solving this problem.
Differential Revision: https://reviews.llvm.org/D29427
llvm-svn: 293941
Summary:
Currently, in the default configuration, the "install" target will
install all llvm executables unversioned, except for three lldb tools
which will be installed versioned (with a non-versioned symlink). This
rectifies that situation.
Reviewers: beanz, sylvestre.ledru, mgorny
Subscribers: ki.stfu, lldb-commits
Differential Revision: https://reviews.llvm.org/D29126
llvm-svn: 293803
This change reverts the lldb-server part of r293686, which is having trouble on Linux bots. I'm not sure if I can make lldb-server work correctly until the full dependency graph is fixed.
llvm-svn: 293690
Summary:
This patch adds accurate dependency specifications to the mail LLDB libraries and tools.
In all cases except lldb-server, these dependencies are added in addition to existing dependencies (making this low risk), and I performed some code cleanup along the way.
For lldb-server I've cleaned up the LLVM dependencies down to just the minimum actually required. This is more than lldb-server actually directly references, and I've left a todo in the code to clean that up.
Reviewers: labath, zturner
Subscribers: lldb-commits, danalbert, srhines, ki.stfu, mgorny, jgosnell
Differential Revision: https://reviews.llvm.org/D29333
llvm-svn: 293686
This adds the LLDB_LOG macro, which enables one to write more succinct log
statements.
if (log)
log->Printf("log something: %d", var);
becomes
LLDB_LOG(log, "log something: {0}, var);
The macro still internally does the "if(log)" dance, so the arguments are only
evaluated if logging is enabled, meaning it has the same overhead as the
previous syntax.
Additionally, the log statements will be automatically prefixed with the file
and function generating the log (if the corresponding new argument to the "log
enable" command is enabled), so one does not need to manually specify this in
the log statement.
It also uses the new llvm formatv syntax, which means we don't have to worry
about PRIx64 macros and similar, and we can log complex object (llvm::StringRef,
lldb_private::Error, ...) more easily.
Differential Revision: https://reviews.llvm.org/D27459
llvm-svn: 292360
Summary:
The NDK cmake toolchain file defines CMAKE_SYSTEM_NAME=Android, so switch the
build to use that. I have also updated the in-tree toolchain file to do that
(instead of defining __ANDROID_NDK__), so it can still be used to build.
After migrating the last bits of non-toolchainy bits out of the in-tree
toolchain, I intend to delete it.
Reviewers: tberghammer, danalbert
Subscribers: srhines, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D28775
llvm-svn: 292212
The llvm_config hack for lldb-server is only necessary for !DYLIB builds, as
otherwise we would get unresolved symbols from lldb libraries which do not track
their dependencies correctly (all of them). In a DYLIB build, the so will
already be added to the link dependencies and we can use that to resolve all
missing symbols.
The proper fix for this would be to have each lldb library track its
dependencies correctly.
llvm-svn: 291555
In LLVM's CMake we have a convention that components have both a build and an install target. Making LLDB follow this convention will allow LLDB to take advantage of the LLVM_DISTRIBUTION_COMPONENTS build option from LLVM.
llvm-svn: 289879
Rationale:
scripts/Python/modules: android is excluded at a higher level, so no point in
checking here
tools/lldb-mi: lldb-mi builds fine (with some cosmetic tweaks) on android, and
there is no reason it shouldn't.
tools/lldb-server: LLDB_DISABLE_LIBEDIT/CURSES already take the platform into
account, so there is no point in checking again.
I am reasonably confident this should not break the build on any platform, but
I'll keep an eye out on the bots.
llvm-svn: 288661
We were referencing a the process class from a register context, which seems
intuitively wrong. Also, the comment above that code is now definitely incorrect,
as ProcessElfCore now does support floating point registers. Also, the code
wasn't really doing anything, as it was just skipping a zero-initialization of a
field that was most likely zero-initialized anyway. Linux elf core FPR test still
passes after this.
llvm-svn: 288237
Stefan Granitz