maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lldb/source/lldb.cpp

84 lines
2.0 KiB
C++
Raw Normal View History

Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
//===-- lldb.cpp ------------------------------------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
#include "lldb/lldb-private.h"
Added a DynamicLoaderStatic plug-in that will act as a static dynamic loader. It will just load all files exactly where the files state they are (file addresses == load addresses). This is used when the llvm::Triple::OSType is set to llvm::Triple::UnknownOS or llvm::Triple::NoOS. llvm-svn: 127053
2011-03-05 09:04:56 +08:00
Fixes for linux building from Stephen Wilson. llvm-svn: 122001
2010-12-17 05:33:41 +08:00
using namespace lldb;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
using namespace lldb_private;
Made lldb.cpp build with clang 5.0. Also removed the use of llvm::raw_string_ostream as it wasn't needed. Also fixed a crasher that could occur when the following line returned a C string tied to a local variable: return OS.str().c_str(); I am guessing "static std::string buf;" was supposed to get assigned to "OS.str()" and then have "buf.c_str()" returned. Modified the non-apple version code to cache its value and not recompute the version every time. llvm-svn: 176274
2013-03-01 02:09:18 +08:00
#include "clang/Basic/Version.h"
[CMake] Generate LLDB_REVISION at build time Summary: This alters the generation of LLDB_REVISION to be heavily based on how clang generates its version header. There are two benefits of this aproach. (1) The LLDB_REVISION is generated at build time, so it will be updated after an SCM pull/update even if CMake doesn't re-run (2) This works on Windows As noted this code is a simplified implementation of the code from clang. Reviewers: tfiala, zturner Subscribers: beanz, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D24846 llvm-svn: 282314
2016-09-24 07:33:52 +08:00
#ifdef HAVE_SVN_VERSION_INC
# include "SVNVersion.inc"
#endif
Unify Darwin and Non-Darwin printing of version output Summary: This change unifies and simplifies the code paths between the Darwin and non-Darwin code to print the LLDB version information. It also introduces a new variable in CMake LLDB_VERSION_STRING which can be used to specify custom version information. On Darwin this value is implicitly set based on the resource/LLDB-Info.plist file. With the LLDB_VERSION_STRING variable set to lldb-360.99.0, the -version output is: > ./bin/lldb -version lldb version 4.0.0 (lldb-360.99.0) clang revision 286264 llvm revision 286265 This behavior is unified across all target platforms. Reviewers: lldb-commits Subscribers: mgorny, tfiala Differential Revision: https://reviews.llvm.org/D26478 llvm-svn: 286479
2016-11-11 01:33:19 +08:00
#ifdef HAVE_APPLE_VERSION_INC
# include "AppleVersion.inc"
#endif
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
static const char *GetLLDBRevision() {
Made lldb.cpp build with clang 5.0. Also removed the use of llvm::raw_string_ostream as it wasn't needed. Also fixed a crasher that could occur when the following line returned a C string tied to a local variable: return OS.str().c_str(); I am guessing "static std::string buf;" was supposed to get assigned to "OS.str()" and then have "buf.c_str()" returned. Modified the non-apple version code to cache its value and not recompute the version every time. llvm-svn: 176274
2013-03-01 02:09:18 +08:00
#ifdef LLDB_REVISION
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
return LLDB_REVISION;
Made lldb.cpp build with clang 5.0. Also removed the use of llvm::raw_string_ostream as it wasn't needed. Also fixed a crasher that could occur when the following line returned a C string tied to a local variable: return OS.str().c_str(); I am guessing "static std::string buf;" was supposed to get assigned to "OS.str()" and then have "buf.c_str()" returned. Modified the non-apple version code to cache its value and not recompute the version every time. llvm-svn: 176274
2013-03-01 02:09:18 +08:00
#else
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
return NULL;
Made lldb.cpp build with clang 5.0. Also removed the use of llvm::raw_string_ostream as it wasn't needed. Also fixed a crasher that could occur when the following line returned a C string tied to a local variable: return OS.str().c_str(); I am guessing "static std::string buf;" was supposed to get assigned to "OS.str()" and then have "buf.c_str()" returned. Modified the non-apple version code to cache its value and not recompute the version every time. llvm-svn: 176274
2013-03-01 02:09:18 +08:00
#endif
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
static const char *GetLLDBRepository() {
Made lldb.cpp build with clang 5.0. Also removed the use of llvm::raw_string_ostream as it wasn't needed. Also fixed a crasher that could occur when the following line returned a C string tied to a local variable: return OS.str().c_str(); I am guessing "static std::string buf;" was supposed to get assigned to "OS.str()" and then have "buf.c_str()" returned. Modified the non-apple version code to cache its value and not recompute the version every time. llvm-svn: 176274
2013-03-01 02:09:18 +08:00
#ifdef LLDB_REPOSITORY
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
return LLDB_REPOSITORY;
Made lldb.cpp build with clang 5.0. Also removed the use of llvm::raw_string_ostream as it wasn't needed. Also fixed a crasher that could occur when the following line returned a C string tied to a local variable: return OS.str().c_str(); I am guessing "static std::string buf;" was supposed to get assigned to "OS.str()" and then have "buf.c_str()" returned. Modified the non-apple version code to cache its value and not recompute the version every time. llvm-svn: 176274
2013-03-01 02:09:18 +08:00
#else
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
return NULL;
Made lldb.cpp build with clang 5.0. Also removed the use of llvm::raw_string_ostream as it wasn't needed. Also fixed a crasher that could occur when the following line returned a C string tied to a local variable: return OS.str().c_str(); I am guessing "static std::string buf;" was supposed to get assigned to "OS.str()" and then have "buf.c_str()" returned. Modified the non-apple version code to cache its value and not recompute the version every time. llvm-svn: 176274
2013-03-01 02:09:18 +08:00
#endif
}
Remove LLDB dependency on xcodeworkspace (on Linux) for version number - make LLDB version number match Clang (and the Debian package) - use the same revision detection magic that Clang uses to report SVN/Git revisions - update test case as per above Example output: $ lldb -v lldb version 3.3 (https://dmalea@llvm.org/svn/llvm-project/lldb/trunk revision 176211 clang revision 176208 llvm revision 176208) ss This line, and those below, will be ignored-- M source/lldb.cpp M test/help/TestHelp.py M source/Makefile llvm-svn: 176268
2013-03-01 00:51:15 +08:00
Fixing the Xcode build that I broke in r286479 Since Xcode can't seem to handle quotes in preprocessor definitions, I've changed the build to assume that the define is unquoted. This should fix the failing Darwin bots. llvm-svn: 286504
2016-11-11 05:30:16 +08:00
#define QUOTE(str) #str
#define EXPAND_AND_QUOTE(str) QUOTE(str)
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
const char *lldb_private::GetVersion() {
// On platforms other than Darwin, report a version number in the same style
// as the clang tool.
static std::string g_version_str;
if (g_version_str.empty()) {
One more cleanup to lldb version printing With this patch LLDB_VERSION_STRING replaces "lldb version x.x.x" if it is set. This allows builds to not display the open source version numbers if the people making the distribution overrides the LLDB_VERSION_STRING. Since LLDB_VERSION_STRING is always overridden on Darwin, this means the first line of lldb -version on Darwin is: lldb-360.99.0 (<repo path> revision <revision>) llvm-svn: 286899
2016-11-15 06:43:08 +08:00
#ifdef LLDB_VERSION_STRING
g_version_str += EXPAND_AND_QUOTE(LLDB_VERSION_STRING);
#else
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
g_version_str += "lldb version ";
g_version_str += CLANG_VERSION_STRING;
One more cleanup to lldb version printing With this patch LLDB_VERSION_STRING replaces "lldb version x.x.x" if it is set. This allows builds to not display the open source version numbers if the people making the distribution overrides the LLDB_VERSION_STRING. Since LLDB_VERSION_STRING is always overridden on Darwin, this means the first line of lldb -version on Darwin is: lldb-360.99.0 (<repo path> revision <revision>) llvm-svn: 286899
2016-11-15 06:43:08 +08:00
#endif
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
const char *lldb_repo = GetLLDBRepository();
const char *lldb_rev = GetLLDBRevision();
One more cleanup to lldb version printing With this patch LLDB_VERSION_STRING replaces "lldb version x.x.x" if it is set. This allows builds to not display the open source version numbers if the people making the distribution overrides the LLDB_VERSION_STRING. Since LLDB_VERSION_STRING is always overridden on Darwin, this means the first line of lldb -version on Darwin is: lldb-360.99.0 (<repo path> revision <revision>) llvm-svn: 286899
2016-11-15 06:43:08 +08:00
if (lldb_repo || lldb_rev) {
g_version_str += " (";
if (lldb_repo)
g_version_str += lldb_repo;
if (lldb_rev) {
g_version_str += " revision ";
g_version_str += lldb_rev;
}
Unify Darwin and Non-Darwin printing of version output Summary: This change unifies and simplifies the code paths between the Darwin and non-Darwin code to print the LLDB version information. It also introduces a new variable in CMake LLDB_VERSION_STRING which can be used to specify custom version information. On Darwin this value is implicitly set based on the resource/LLDB-Info.plist file. With the LLDB_VERSION_STRING variable set to lldb-360.99.0, the -version output is: > ./bin/lldb -version lldb version 4.0.0 (lldb-360.99.0) clang revision 286264 llvm revision 286265 This behavior is unified across all target platforms. Reviewers: lldb-commits Subscribers: mgorny, tfiala Differential Revision: https://reviews.llvm.org/D26478 llvm-svn: 286479
2016-11-11 01:33:19 +08:00
g_version_str += ")";
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
One more cleanup to lldb version printing With this patch LLDB_VERSION_STRING replaces "lldb version x.x.x" if it is set. This allows builds to not display the open source version numbers if the people making the distribution overrides the LLDB_VERSION_STRING. Since LLDB_VERSION_STRING is always overridden on Darwin, this means the first line of lldb -version on Darwin is: lldb-360.99.0 (<repo path> revision <revision>) llvm-svn: 286899
2016-11-15 06:43:08 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
std::string clang_rev(clang::getClangRevision());
if (clang_rev.length() > 0) {
Unify Darwin and Non-Darwin printing of version output Summary: This change unifies and simplifies the code paths between the Darwin and non-Darwin code to print the LLDB version information. It also introduces a new variable in CMake LLDB_VERSION_STRING which can be used to specify custom version information. On Darwin this value is implicitly set based on the resource/LLDB-Info.plist file. With the LLDB_VERSION_STRING variable set to lldb-360.99.0, the -version output is: > ./bin/lldb -version lldb version 4.0.0 (lldb-360.99.0) clang revision 286264 llvm revision 286265 This behavior is unified across all target platforms. Reviewers: lldb-commits Subscribers: mgorny, tfiala Differential Revision: https://reviews.llvm.org/D26478 llvm-svn: 286479
2016-11-11 01:33:19 +08:00
g_version_str += "\n clang revision ";
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
g_version_str += clang_rev;
}
std::string llvm_rev(clang::getLLVMRevision());
if (llvm_rev.length() > 0) {
Unify Darwin and Non-Darwin printing of version output Summary: This change unifies and simplifies the code paths between the Darwin and non-Darwin code to print the LLDB version information. It also introduces a new variable in CMake LLDB_VERSION_STRING which can be used to specify custom version information. On Darwin this value is implicitly set based on the resource/LLDB-Info.plist file. With the LLDB_VERSION_STRING variable set to lldb-360.99.0, the -version output is: > ./bin/lldb -version lldb version 4.0.0 (lldb-360.99.0) clang revision 286264 llvm revision 286265 This behavior is unified across all target platforms. Reviewers: lldb-commits Subscribers: mgorny, tfiala Differential Revision: https://reviews.llvm.org/D26478 llvm-svn: 286479
2016-11-11 01:33:19 +08:00
g_version_str += "\n llvm revision ";
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
g_version_str += llvm_rev;
}
Unify Darwin and Non-Darwin printing of version output Summary: This change unifies and simplifies the code paths between the Darwin and non-Darwin code to print the LLDB version information. It also introduces a new variable in CMake LLDB_VERSION_STRING which can be used to specify custom version information. On Darwin this value is implicitly set based on the resource/LLDB-Info.plist file. With the LLDB_VERSION_STRING variable set to lldb-360.99.0, the -version output is: > ./bin/lldb -version lldb version 4.0.0 (lldb-360.99.0) clang revision 286264 llvm revision 286265 This behavior is unified across all target platforms. Reviewers: lldb-commits Subscribers: mgorny, tfiala Differential Revision: https://reviews.llvm.org/D26478 llvm-svn: 286479
2016-11-11 01:33:19 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
return g_version_str.c_str();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}