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
Summary:
This replaces all the uses of the __ANDROID_NDK__ define with __ANDROID__. This
is a preparatory step to remove our custom android toolchain file and rely on
the standard android NDK one instead, which does not provide this define.
Instead I rely, on __ANDROID__, which is set by the compiler.
I haven't yet removed the cmake variable with the same name, as we will need to
do something completely different there -- NDK toolchain defines
CMAKE_SYSTEM_NAME to Android, while our current one pretends it's linux.
Reviewers: tberghammer, zturner
Subscribers: danalbert, srhines, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D27305
llvm-svn: 288494
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
It seems a debug build of lldb-server will not complete without these, as the
linker is not able to strip out code that aggressively. Add those back until I
can figure out how to break the dependency chains.
llvm-svn: 288181
I don't believe the code in those plugins could be in any way useful for
lldb-server, but I can't be sure if this will break some transitive dependencies.
Builtbots should be able to tell us that.
llvm-svn: 288169
Summary:
This basically just inlines the LLDBDependencies.cmake file into lldb-server
CMakeLists.txt. The reason is that most of these dependencies are not actually
necessary for lldb-server (some of them can't be removed because of
cross-dependencies, but most of the plugins can). I intend to start cleaning
these up in follow-up commits, but I want to do this first, so the subsequent
ones can be easily reverted if they don't build in some configurations.
When I cleaned these up locally, I was able to get a 30%--50% improvement in
lldb-server size.
Reviewers: zturner, beanz, tfiala
Subscribers: danalbert, srhines, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D26975
llvm-svn: 288159
Summary:
This replaces the usage of raw integers with duration classes in the gdb-remote
packet management functions. The values are still converted back to integers once
they go into the generic Communication class -- that I am leaving to a separate
change.
The changes are mostly straight-forward (*), the only tricky part was
representation of infinite timeouts.
Currently, we use UINT32_MAX to denote infinite timeout. This is not well suited
for duration classes, as they tend to do arithmetic on the values, and the
identity of the MAX value can easily get lost (e.g.
microseconds(seconds(UINT32_MAX)).count() != UINT32_MAX). We cannot use zero to
represent infinity (as Listener classes do) because we already use it to do
non-blocking polling reads. For this reason, I chose to have an explicit value
for infinity.
The way I achieved that is via llvm::Optional, and I think it reads quite
natural. Passing llvm::None as "timeout" means "no timeout", while passing zero
means "poll". The only tricky part is this breaks implicit conversions (seconds
are implicitly convertible to microseconds, but Optional<seconds> cannot be
easily converted into Optional<microseconds>). For this reason I added a special
class Timeout, inheriting from Optional, and enabling the necessary conversions
one would normally expect.
(*) The other tricky part was GDBRemoteCommunication::PopPacketFromQueue, which
was needlessly complicated. I've simplified it, but that one is only used in
non-stop mode, and so is untested.
Reviewers: clayborg, zturner, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D26971
llvm-svn: 287864
This is to fix a regression in remote-linux lldb-server connections.
We were wrongly passing a copy of uri and expecting a stringRef back.
llvm-svn: 287542
This is a large API change that removes the two functions from
StreamString that return a std::string& and a const std::string&,
and instead provide one function which returns a StringRef.
Direct access to the underlying buffer violates the concept of
a "stream" which is intended to provide forward only access,
and makes porting to llvm::raw_ostream more difficult in the
future.
Differential Revision: https://reviews.llvm.org/D26698
llvm-svn: 287152
This is forcing to use Error::success(), which is in a wide majority
of cases a lot more readable.
Differential Revision: https://reviews.llvm.org/D26481
llvm-svn: 286561
Summary:
liblldb does not re-export the llvm library contained within, so lldb-mi needs to
manage its own dependencies. Right now it only uses the llvm support library.
Reviewers: beanz, zturner, tfiala, clayborg, abidh
Subscribers: ki.stfu, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D26190
llvm-svn: 285894
Summary: This tool is only built on Darwin, and the name darwin-debug matches the Xcode project. We should have this in sync unless there is a good reason not to.
Reviewers: zturner, tfiala, labath
Subscribers: labath, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D25745
llvm-svn: 285356
Summary:
The dependencies of our libraries (only liblldb, really) we marked as public, which caused all
their dependencies to be repeated when linking any executables to them. This is a problem because
then all the .a files could end up being linked twice, once to liblldb and once
again to to the executable linking against liblldb (lldb, lldb-mi). As it turns out,
our build actually depends on this behavior:
- on windows, lldb does not have getopt, so it pulls it from inside liblldb, even
though getopt is not a part of the exported interface of liblldb (maybe some of
the bsd variants have this problem as well)
- lldb-mi uses llvm, which again is not exported by liblldb
This change does not actually fix these problems (that is going to be a hard
one), but it does make them explicit by moving this magic from add_lldb_library
to the places the executable targets are defined. That way, I can link the
additional .a files only on targets that really need it, and the other targets
can build cleanly and make sure we don't regress further. It also fixes the
LLVM_LINK_LLVM_DYLIB build on linux.
Reviewers: zturner, beanz
Subscribers: ki.stfu, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D25680
llvm-svn: 284466
Summary:
When extracting options for long options (starting with `--`), the use of
`MIUtilString::SplitConsiderQuotes` to split all the arguments was being
conditioned on the option type to be expected. This was wrong as this caused
other options to be parsed incorrectly since it was not taking into account the
presence of quotes.
Patch by Ed Munoz <edmunoz@microsoft.com>
Reviewers: edmunoz, ki.stfu
Subscribers: ki.stfu, lldb-commits
Projects: #lldb
Differential Revision: https://reviews.llvm.org/D24202
llvm-svn: 282135
Summary:
This patch adds a CMake option LLDB_BUILD_FRAMEWORK, which builds libLLDB as a macOS framework instead of as a *nix shared library.
With this patch any LLDB executable that has the INCLUDE_IN_FRAMEWORK option set will be built into the Framework's resources directory, and a symlink to the exeuctable will be placed under the build directory's bin folder. Creating the symlinks allows users to run commands from the build directory without altering the workflow.
The framework generated by this patch passes the LLDB test suite, but has not been tested beyond that. It is not expected to be fully ready to ship, but it is a first step.
With this patch binaries that are placed inside the framework aren't being properly installed. Fixing that would increase the patch size significantly, so I'd like to do that in a follow-up.
Reviewers: zturner, tfiala
Subscribers: beanz, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D24749
llvm-svn: 282110
The class is only used in the debugserver. The rest of lldb has the StringExtractor class.
Xcode project will need to be updated after this.
llvm-svn: 281226
Summary: This patch adds a new test and fixes extra new-line before exit
Reviewers: abidh
Subscribers: ki.stfu, dawn, lldb-commits, abidh
Differential Revision: https://reviews.llvm.org/D9740
llvm-svn: 281199
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:
Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):
find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;
The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.
Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.
llvm-svn: 280751
Summary:
Replace uses of the local MIUtilParse::CRegexParser class with the LLVM support class llvm::Regex. This reduces duplication of code, and makes it possible to remove the MIUtilParse::CRegexParser class that requires LLVM internal implementation headers.
Bug: https://llvm.org/bugs/show_bug.cgi?id=29138
Reviewers: dawn, abidh, ki.stfu
Subscribers: labath, ki.stfu, lldb-commits
Differential Revision: https://reviews.llvm.org/D23882
Author: Michał Górny <mgorny@gentoo.org>
llvm-svn: 280662
This code represents the Week of Code work I did on bringing up
lldb-server LLGS support for Darwin. It does not include the
Xcode project changes needed, as we don't want to throw that switch
until more support is implemented (i.e. this change is inert, no
build systems use it yet. I've verified on Ubuntu 16.04, macOS
Xcode and macOS cmake builds).
This change does some minimal refactoring of code that is shared
with the Linux LLGS portion, moving it from NativeProcessLinux into
NativeProcessProtocol. That code is also used by NativeProcessDarwin.
Current state on Darwin:
* Process launching is implemented. (Attach is not).
Launching on devices has not yet been tested (FBS/BKS might
need a bit of work).
* Inferior waitpid monitoring and communication of exit status
via MainLoop callback is implemented.
* Memory read/write, breakpoints, thread register context, etc.
are not yet implemented. This impacts process stop/resume, as
the initial launch suspended immediately starts the process
up and running because it doesn't know it is supposed to remain
stopped.
* I implemented the equivalent of MachThreadList as
NativeThreadListDarwin, in anticipation that we might want to
factor out common parts into NativeThreadList{Protocol} and share
some code here. After writing it, though, the fallout from merging
Mach Task/Process into a single concept plus some other minor
changes makes the whole NativeThreadListDarwin concept nothing more
than dead weight. I am likely going to get rid of this class and
just manage it directly in NativeProcessDarwin, much like I did
for NativeProcessLinux.
* There is a stub-out call for starting a STDIO thread. That will
go away and adopt the MainLoop pselect-based IOObject reading.
I am developing the fully-integrated changes in the following repo,
which contains the necessary Xcode bits and the glue that enables
lldb-debugserver on a macOS system:
https://github.com/tfiala/lldb/tree/llgs-darwin
This change also breaks out a few of the lldb-server tests into
their own directory, and adds some $qHostInfo tests (not sure why
I didn't write those tests back when I initially implemented that
on the Linux side).
llvm-svn: 280604
I have some improvements to make to StringExtractor that require
using LLVM. debugserver can't take a dependency on LLVM but uses
this file, so I'm forking it off into StdStringExtractor and
StringExtractor, so that StringExtractor can take advantage of
some performance improvements and readability improvements that
LLVM can provide.
llvm-svn: 279997
Summary:
Moving a temporary object prevents copy elision, which is exactly
what clang points out by warning about this pattern.
The fix is simply removal of std::move applied to temporary objects.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D23825
Author: Taras Tsugrii <ttsugrii@fb.com>
llvm-svn: 279724
Take 2, with missing cmake line fixed. Build tested on
Ubuntu 14.04 with clang-3.6.
See docs/structured_data/StructuredDataPlugins.md for details.
differential review: https://reviews.llvm.org/D22976
reviewers: clayborg, jingham
llvm-svn: 279202
This change opens a socket pair and passes the second socket pair file descriptor down to the debugserver binary using a new option: "--fd=N" where N is the file descriptor. This file descriptor gets passed via posix_spawn() so that there is no need to do any bind/listen or bind/accept calls and eliminates the hanshake unix socket that is used to pass the result of the actual port that ends up being used so it can save time on launch as well as being faster.
This is currently only enabled on __APPLE__ builds. Other OSs should try modifying the #define from ProcessGDBRemote.cpp but the first person will need to port the --fd option over to lldb-server. Any OSs that enable USE_SOCKETPAIR_FOR_LOCAL_CONNECTION in their native builds can use the socket pair stuff. The #define is Apple only right now, but looks like:
#if defined (__APPLE__)
#define USE_SOCKETPAIR_FOR_LOCAL_CONNECTION 1
#endif
<rdar://problem/27814880>
llvm-svn: 278524
It's always hard to remember when to include this file, and
when you do include it it's hard to remember what preprocessor
check it needs to be behind, and then you further have to remember
whether it's windows.h or win32.h which you need to include.
This patch changes the name to PosixApi.h, which is more appropriately
named, and makes it independent of any preprocessor setting.
There's still the issue of people not knowing when to include this,
because there's not a well-defined set of things it exposes other
than "whatever is missing on Windows", but at least this should
make it less painful to fix when problems arise.
This patch depends on LLVM revision r278170.
llvm-svn: 278177
It only contained a reimplementation of std::to_string, which I have replaced with usages of
pre-existing llvm::to_string (also, injecting members into the std namespace is evil).
llvm-svn: 278000
Summary:
When trying to parse the -break-insert arguments as a named location, the string parsing was not configured to allow directory paths. This patch adds a constructor to allow the parsing of string as directory path along with the other parameters.
This fixes https://llvm.org/bugs/show_bug.cgi?id=28709
Patch from malaperle@gmail.com
Reviewers: clayborg, ki.stfu
Subscribers: lldb-commits, ki.stfu
Differential Revision: https://reviews.llvm.org/D22902
llvm-svn: 277117
for the fall (northern hemisphere) 2016 Darwin platforms to learn
about loaded images, instead of reading dyld internal data structures.
These new SPI don't exist on older releases, and new packets are
needed from debugserver to use them (those changes are already committed).
I had to change the minimum deployment target for debugserver in the xcode
project file to macOS 10.10 so that debugserver will use the
[[NSProcessInfo processInfo] operatingSystemVersion]
call in MachProcess::GetOSVersionNumbers to get the operarting system
version # -- this API is only available in macOS 10.10 and newer
("OS X Yosemite", released Oct 2014). If we have many people building
llvm.org lldb on older systems still, we can back off on this for the
llvm.org sources.
There should be no change in behavior with this commit, either to
older darwin systems or newer darwin systems.
For now the new DynamicLoader plugin is never activated - I'm forcing
the old plugin to be used in DynamicLoaderDarwin::UseDYLDSPI.
I'll remove that unconditional use of the old plugin soon, so the
newer plugin is used on the newest Darwin platforms.
<rdar://problem/25251243>
llvm-svn: 276254
Jason Molenda