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
This is better for a number of reasons. Mostly style, but also:
1) Signed-unsigned comparison warnings disappear since there is
no loop index.
2) Iterating with the range-for style gives you back an entry
that has more than just a const char*, so it's more efficient
and more useful.
3) Makes code safter since the type system enforces that it's
impossible to index out of bounds.
llvm-svn: 283413
*** 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:
We've had two copies of code for launching processes:
- one in NativeProcessLinux, used for launching debugged processes
- one in ProcessLauncherAndroid, used on android for launching all other kinds of processes
These have over time acquired support for various launch options, but neither supported all of
them. I now replace them with a single implementation ProcessLauncherLinux, which supports all
the options the individual versions supported and set it to be used to launch all processes on
linux.
This also works around the ETXTBSY issue on android when the process is started from the platform
instance, as that used to go through the version which did not contain the workaround.
Reviewers: tberghammer
Subscribers: tberghammer, danalbert, srhines, lldb-commits
Differential Revision: https://reviews.llvm.org/D22457
llvm-svn: 276288
Pavel Labath