[Lldb-commits] [PATCH] D48177: Suppress SIGSEGV on Android when the program will recover
labath added a comment.
Thank you for implementing this. We've had code like this in android studio for
a long time, but it's definitely better doing it in lldb instead.
I'll give some more background so that Jim and anyone else looking at this can
understand what's going on. These files (I forgot what's the difference between
them) contain the compiled version of Java code. As java is a "safe" language,
the code should not generate any signals (modulo compiler bugs) that the
runtime can't handle. The SEGV is just the implementation's way of avoiding
null checks everywhere -- on the assumption that NullPointerExceptions are
rare, its faster to not generate them and clean up the occasional mess in the
signal handler.
For that reason, an android app (*) will always have a SEGV handler. This
handler will be invoked even for non-bening SEGVs (so simply resuming from a
SEGV will never crash the app immediately). For signals the runtime can't
handle it will invoke a special `art_sigsegv_fault` function, which the
debugger can hook to catch "real" segfaults. Unfortunately, in the past this
mechanism was unreliable (the function could end up inlined), so we have to do
this dance instead. Once android versions with the fixed "fault" function
become more prevalent, we can skip this and just automatically reinject all
SIGSEGVs. This is particularly important as each new version of android finds
new creative ways to "optimize" things via SIGSEGVs, and going things this way
means constantly playing catch-up.
So much for background. I think Jim's suggestion on having all of this this
controllable by a setting makes sense, and it would be consistent with how we
handle other kinds of "magical" under-the-hood stops
(target.process.stop-on-sharedlibrary-events). I'm not sure how much use would
it get, but I can imagine it being useful for debugging the segv handling code
itself. I'm a bit sad that we now have two plugins with the `OverrideStopInfo`
functionality, but I can't think of any better way of arranging things right
now.
(*) This means "real" GUI apps. command line executables will not have the
android runtime inside them, nor the special segv handler, but that means they
will not contain any "dex" files either.
Comment at: source/Plugins/Platform/Android/PlatformAndroid.cpp:399
+// Define a SIGSEGV that doesn't require any headers
+#define ANDROID_SIGSEGV 11
+
I'm not sure if SEGV is one of them, but numbers of some signals vary between
architectures. You should be able to get the real value via
process->GetUnixSignals()
Comment at: source/Plugins/Platform/Android/PlatformAndroid.cpp:424
+ // We are lookking for .dex, .odex, and .oat files.
+ if (ext_ref.endswith("dex") || ext_ref.endswith("oat")) {
+// We have a SIGSEGV we need to mute
jingham wrote:
> Given that this is a pretty big behavior change, I would exactly match on the
> three extensions rather than use endswith, so it only affects the file types
> you care about.
Agreed, matching on the exact extension looks safer and more obvious. The most
llvm-y way of writing that would be
`StringSwitch(ext.GetStringRef()).Cases("dex", "oat", "odex",
true).Default(false)`
https://reviews.llvm.org/D48177
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D47889: Use llvm::VersionTuple instead of manual version marshalling
labath updated this revision to Diff 151484.
labath added a comment.
Fix a typo in netbsd code.
https://reviews.llvm.org/D47889
Files:
include/lldb/Core/Module.h
include/lldb/Host/freebsd/HostInfoFreeBSD.h
include/lldb/Host/linux/HostInfoLinux.h
include/lldb/Host/macosx/HostInfoMacOSX.h
include/lldb/Host/netbsd/HostInfoNetBSD.h
include/lldb/Host/windows/HostInfoWindows.h
include/lldb/Interpreter/OptionGroupPlatform.h
include/lldb/Symbol/ObjectFile.h
include/lldb/Target/Platform.h
include/lldb/Target/Process.h
include/lldb/Utility/Args.h
source/API/SBModule.cpp
source/API/SBPlatform.cpp
source/Core/Module.cpp
source/Host/freebsd/HostInfoFreeBSD.cpp
source/Host/linux/HostInfoLinux.cpp
source/Host/macosx/objcxx/HostInfoMacOSX.mm
source/Host/netbsd/HostInfoNetBSD.cpp
source/Host/windows/HostInfoWindows.cpp
source/Interpreter/OptionGroupPlatform.cpp
source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
source/Plugins/DynamicLoader/POSIX-DYLD/DYLDRendezvous.cpp
source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntime.cpp
source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.h
source/Plugins/Platform/Android/PlatformAndroid.cpp
source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
source/Plugins/Platform/MacOSX/PlatformDarwin.h
source/Plugins/Platform/MacOSX/PlatformRemoteDarwinDevice.cpp
source/Plugins/Platform/MacOSX/PlatformRemoteDarwinDevice.h
source/Plugins/Platform/POSIX/PlatformPOSIX.cpp
source/Plugins/Platform/Windows/PlatformWindows.cpp
source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.cpp
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp
source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
source/Target/Platform.cpp
source/Utility/Args.cpp
unittests/Platform/PlatformDarwinTest.cpp
Index: unittests/Platform/PlatformDarwinTest.cpp
===
--- unittests/Platform/PlatformDarwinTest.cpp
+++ unittests/Platform/PlatformDarwinTest.cpp
@@ -19,38 +19,29 @@
using namespace lldb_private;
TEST(PlatformDarwinTest, TestParseVersionBuildDir) {
- uint32_t A, B, C;
+ llvm::VersionTuple V;
llvm::StringRef D;
- std::tie(A, B, C, D) = PlatformDarwin::ParseVersionBuildDir("1.2.3 (test1)");
- EXPECT_EQ(1u, A);
- EXPECT_EQ(2u, B);
- EXPECT_EQ(3u, C);
+ std::tie(V, D) = PlatformDarwin::ParseVersionBuildDir("1.2.3 (test1)");
+ EXPECT_EQ(llvm::VersionTuple(1, 2, 3), V);
EXPECT_EQ("test1", D);
- std::tie(A, B, C, D) = PlatformDarwin::ParseVersionBuildDir("2.3 (test2)");
- EXPECT_EQ(2u, A);
- EXPECT_EQ(3u, B);
+ std::tie(V, D) = PlatformDarwin::ParseVersionBuildDir("2.3 (test2)");
+ EXPECT_EQ(llvm::VersionTuple(2, 3), V);
EXPECT_EQ("test2", D);
- std::tie(A, B, C, D) = PlatformDarwin::ParseVersionBuildDir("3 (test3)");
- EXPECT_EQ(3u, A);
+ std::tie(V, D) = PlatformDarwin::ParseVersionBuildDir("3 (test3)");
+ EXPECT_EQ(llvm::VersionTuple(3), V);
EXPECT_EQ("test3", D);
- std::tie(A, B, C, D) = PlatformDarwin::ParseVersionBuildDir("1.2.3 (test");
- EXPECT_EQ(1u, A);
- EXPECT_EQ(2u, B);
- EXPECT_EQ(3u, C);
+ std::tie(V, D) = PlatformDarwin::ParseVersionBuildDir("1.2.3 (test");
+ EXPECT_EQ(llvm::VersionTuple(1, 2, 3), V);
EXPECT_EQ("test", D);
- std::tie(A, B, C, D) = PlatformDarwin::ParseVersionBuildDir("2.3.4 test");
- EXPECT_EQ(2u, A);
- EXPECT_EQ(3u, B);
- EXPECT_EQ(4u, C);
+ std::tie(V, D) = PlatformDarwin::ParseVersionBuildDir("2.3.4 test");
+ EXPECT_EQ(llvm::VersionTuple(2, 3, 4), V);
EXPECT_EQ("", D);
- std::tie(A, B, C, D) = PlatformDarwin::ParseVersionBuildDir("3.4.5");
- EXPECT_EQ(3u, A);
- EXPECT_EQ(4u, B);
- EXPECT_EQ(5u, C);
+ std::tie(V, D) = PlatformDarwin::ParseVersionBuildDir("3.4.5");
+ EXPECT_EQ(llvm::VersionTuple(3, 4, 5), V);
}
Index: source/Utility/Args.cpp
===
--- source/Utility/Args.cpp
+++ source/Utility/Args.cpp
@@ -409,29 +409,6 @@
return s.c_str();
}
-bool Args::StringToVersion(llvm::StringRef string, uint32_t &major,
- uint32_t &minor, uint32_t &update) {
- major = UINT32_MAX;
- minor = UINT32_MAX;
- update = UINT32_MAX;
-
- if (string.empty())
-return false;
-
- llvm::StringRef major_str, minor_str, update_str;
-
- std::tie(major_str, minor_str) = string.split('.');
- std::tie(minor_str, update_str) = minor_str.split('.');
- if (major_str.getAsInteger(10, major))
-return false;
- if (!minor_str.empty() && minor_str.getAsInteger(10, minor))
-return false;
- if (!update_str.empty() && update_str.getAsInteger(10, update))
-return false;
-
- return true;
-}
-
const char *Args::GetShellSafeArgu
[Lldb-commits] [PATCH] D48215: Remove dependency from Host to python
labath created this revision.
labath added reviewers: zturner, jingham, davide.
Herald added a subscriber: mgorny.
The only reason python was used in the Host module was to compute the
python path. I resolve this the same way as https://reviews.llvm.org/D47384 did
for clang, moving
the path computation into the python plugin and modifying SBHostOS class
to call into this module for ePathTypePythonDir.
https://reviews.llvm.org/D48215
Files:
include/lldb/Host/macosx/HostInfoMacOSX.h
include/lldb/Host/posix/HostInfoPosix.h
include/lldb/Host/windows/HostInfoWindows.h
source/API/SBHostOS.cpp
source/Host/CMakeLists.txt
source/Host/common/HostInfoBase.cpp
source/Host/macosx/objcxx/HostInfoMacOSX.mm
source/Host/posix/HostInfoPosix.cpp
source/Host/windows/HostInfoWindows.cpp
source/Plugins/ScriptInterpreter/Python/CMakeLists.txt
source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h
Index: source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h
===
--- source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h
+++ source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h
@@ -445,6 +445,8 @@
static const char *GetPluginDescriptionStatic();
+ static FileSpec GetPythonDir();
+
//--
// PluginInterface protocol
//--
@@ -509,6 +511,10 @@
static void AddToSysPath(AddLocation location, std::string path);
+ static void ComputePythonDirForApple(llvm::SmallVectorImpl &path);
+ static void ComputePythonDirForPosix(llvm::SmallVectorImpl &path);
+ static void ComputePythonDirForWindows(llvm::SmallVectorImpl &path);
+
bool EnterSession(uint16_t on_entry_flags, FILE *in, FILE *out, FILE *err);
void LeaveSession();
Index: source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
===
--- source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -347,6 +347,71 @@
return "Embedded Python interpreter";
}
+void ScriptInterpreterPython::ComputePythonDirForApple(
+llvm::SmallVectorImpl &path) {
+ auto style = llvm::sys::path::Style::posix;
+
+ llvm::StringRef path_ref(path.begin(), path.size());
+ auto rbegin = llvm::sys::path::rbegin(path_ref, style);
+ auto rend = llvm::sys::path::rend(path_ref);
+ auto framework = std::find(rbegin, rend, "LLDB.framework");
+ if (framework == rend) {
+ComputePythonDirForPosix(path);
+return;
+ }
+ path.resize(framework - rend);
+ llvm::sys::path::append(path, style, "LLDB.framework", "Resources", "Python");
+}
+
+void ScriptInterpreterPython::ComputePythonDirForPosix(
+llvm::SmallVectorImpl &path) {
+ auto style = llvm::sys::path::Style::posix;
+#if defined(LLDB_PYTHON_RELATIVE_LIBDIR)
+ // Build the path by backing out of the lib dir, then building with whatever
+ // the real python interpreter uses. (e.g. lib for most, lib64 on RHEL
+ // x86_64).
+ llvm::sys::path::remove_filename(path, style);
+ llvm::sys::path::append(path, style, LLDB_PYTHON_RELATIVE_LIBDIR);
+#else
+ llvm::sys::path::append(path, style,
+ "python" + llvm::Twine(PY_MAJOR_VERSION) + "." +
+ llvm::Twine(PY_MINOR_VERSION),
+ "site-packages");
+#endif
+}
+
+void ScriptInterpreterPython::ComputePythonDirForWindows(
+llvm::SmallVectorImpl &path) {
+ auto style = llvm::sys::path::Style::windows;
+ llvm::sys::path::remove_filename(path, style);
+ llvm::sys::path::append(path, style, "lib", "site-packages");
+
+ // This will be injected directly through FileSpec.GetDirectory().SetString(),
+ // so we need to normalize manually.
+ std::replace(path.begin(), path.end(), '\\', '/');
+}
+
+FileSpec ScriptInterpreterPython::GetPythonDir() {
+ static FileSpec g_spec = []() {
+FileSpec spec;
+if (!HostInfo::GetLLDBPath(lldb::ePathTypeLLDBShlibDir, spec))
+ return FileSpec();
+llvm::SmallString<64> path;
+spec.GetPath(path);
+
+#if defined(__APPLE__)
+ComputePythonDirForApple(path);
+#elif defined(_WIN32)
+ComputePythonDirForWindows(path);
+#else
+ComputePythonDirForPosix(path);
+#endif
+spec.GetDirectory().SetString(path);
+return spec;
+ }();
+ return g_spec;
+}
+
lldb_private::ConstString ScriptInterpreterPython::GetPluginName() {
return GetPluginNameStatic();
}
@@ -3094,13 +3159,13 @@
PyRun_SimpleString("import sys");
AddToSysPath(AddLocation::End, ".");
- FileSpec file_spec;
// Don't denormalize paths when calling file_spec.GetPath(). On platforms
// that use a backslash as the path separator, this will result in executing
// python code con
[Lldb-commits] [PATCH] D48212: Revert "[lldb-mi] Add overload method for setting an error"
clayborg accepted this revision. clayborg added a comment. This revision is now accepted and ready to land. I didn't remember we already did this in SBError... Sorry about that. https://reviews.llvm.org/D48212 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D48215: Remove dependency from Host to python
clayborg added inline comments. Comment at: source/API/SBHostOS.cpp:48 + case ePathTypePythonDir: +fspec = ScriptInterpreterPython::GetPythonDir(); +break; Why is this here instead of inside of "HostInfo::GetLLDBPath(path_type, fspec);"? Does this mean internal code that calls: ``` HostInfo::GetLLDBPath(ePathTypePythonDir, fspec); ``` Won't work anymore? Also same for ePathTypeClangDir? Are we trying to solve a layering problems by hosing over internal clients? https://reviews.llvm.org/D48215 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D48215: Remove dependency from Host to python
The internal api has no guarantees as to its stability. On Fri, Jun 15, 2018 at 7:48 AM Greg Clayton via Phabricator < revi...@reviews.llvm.org> wrote: > clayborg added inline comments. > > > > Comment at: source/API/SBHostOS.cpp:48 > + case ePathTypePythonDir: > +fspec = ScriptInterpreterPython::GetPythonDir(); > +break; > > Why is this here instead of inside of "HostInfo::GetLLDBPath(path_type, > fspec);"? Does this mean internal code that calls: > > ``` > HostInfo::GetLLDBPath(ePathTypePythonDir, fspec); > ``` > > Won't work anymore? Also same for ePathTypeClangDir? Are we trying to > solve a layering problems by hosing over internal clients? > > > https://reviews.llvm.org/D48215 > > > > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D48215: Remove dependency from Host to python
zturner added a subscriber: labath. zturner added a comment. The internal api has no guarantees as to its stability. https://reviews.llvm.org/D48215 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D48215: Remove dependency from Host to python
clayborg added a comment. In https://reviews.llvm.org/D48215#1133695, @zturner wrote: > The internal api has no guarantees as to its stability. What do you mean by this? If we have an internal API that claims to give out paths, it should give out paths. What am I missing here? https://reviews.llvm.org/D48215 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D48215: Remove dependency from Host to python
It can assert when we pass the python or clang directory enumeration. We could also remove the values from the internal enumeration but keep them in the public enumeration. However, we can’t be forced into providing a stable internal api just because we must provide a stable public api. On Fri, Jun 15, 2018 at 8:29 AM Greg Clayton via Phabricator < revi...@reviews.llvm.org> wrote: > clayborg added a comment. > > In https://reviews.llvm.org/D48215#1133695, @zturner wrote: > > > The internal api has no guarantees as to its stability. > > > What do you mean by this? If we have an internal API that claims to give > out paths, it should give out paths. What am I missing here? > > > https://reviews.llvm.org/D48215 > > > > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D48215: Remove dependency from Host to python
zturner added a comment. It can assert when we pass the python or clang directory enumeration. We could also remove the values from the internal enumeration but keep them in the public enumeration. However, we can’t be forced into providing a stable internal api just because we must provide a stable public api. https://reviews.llvm.org/D48215 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D48215: Remove dependency from Host to python
labath added a comment. Actually, my plan was to follow this up with a patch which removes usages of that enumeration from the internal api altogether (basically do a `s/GetLLDBPath(ePathTypeXXX/GetXXXPath`). That should make the internal api nicer, and provide a clean separation between the internal and public api (thereby taking pressure off of adding new enums to the public api just because we have a new kind of an internal path). I was considering in which order to submit the patches. In the end I chose this one because it will make the second patch slightly smaller, but I can do it in the other order too... https://reviews.llvm.org/D48215 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D48215: Remove dependency from Host to python
labath added a comment. (pressed return too soon) Would that address your reservations about this idea? https://reviews.llvm.org/D48215 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D48215: Remove dependency from Host to python
clayborg added a comment. It might be nice to start with the removal of HostInfo::GetLLDBPath(...) first and fixing up all call sites that use that API to use the new internally sanctioned versions. Then submit this patch? https://reviews.llvm.org/D48215 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D48215: Remove dependency from Host to python
clayborg added a comment. In https://reviews.llvm.org/D48215#1133725, @labath wrote: > (pressed return too soon) > > Would that address your reservations about this idea? yeah, just don't like the idea of HostInfo::GetLLDBPath() being non functional. https://reviews.llvm.org/D48215 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D48215: Remove dependency from Host to python
labath planned changes to this revision. labath added a comment. Ok, I'll start with the other patch first. https://reviews.llvm.org/D48215 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D48177: Suppress SIGSEGV on Android when the program will recover
Thanks for the explanation!
Jim
> On Jun 15, 2018, at 2:35 AM, Pavel Labath via Phabricator
> wrote:
>
> labath added a comment.
>
> Thank you for implementing this. We've had code like this in android studio
> for a long time, but it's definitely better doing it in lldb instead.
>
> I'll give some more background so that Jim and anyone else looking at this
> can understand what's going on. These files (I forgot what's the difference
> between them) contain the compiled version of Java code. As java is a "safe"
> language, the code should not generate any signals (modulo compiler bugs)
> that the runtime can't handle. The SEGV is just the implementation's way of
> avoiding null checks everywhere -- on the assumption that
> NullPointerExceptions are rare, its faster to not generate them and clean up
> the occasional mess in the signal handler.
> For that reason, an android app (*) will always have a SEGV handler. This
> handler will be invoked even for non-bening SEGVs (so simply resuming from a
> SEGV will never crash the app immediately). For signals the runtime can't
> handle it will invoke a special `art_sigsegv_fault` function, which the
> debugger can hook to catch "real" segfaults. Unfortunately, in the past this
> mechanism was unreliable (the function could end up inlined), so we have to
> do this dance instead. Once android versions with the fixed "fault" function
> become more prevalent, we can skip this and just automatically reinject all
> SIGSEGVs. This is particularly important as each new version of android finds
> new creative ways to "optimize" things via SIGSEGVs, and going things this
> way means constantly playing catch-up.
>
> So much for background. I think Jim's suggestion on having all of this this
> controllable by a setting makes sense, and it would be consistent with how we
> handle other kinds of "magical" under-the-hood stops
> (target.process.stop-on-sharedlibrary-events). I'm not sure how much use
> would it get, but I can imagine it being useful for debugging the segv
> handling code itself. I'm a bit sad that we now have two plugins with the
> `OverrideStopInfo` functionality, but I can't think of any better way of
> arranging things right now.
>
> (*) This means "real" GUI apps. command line executables will not have the
> android runtime inside them, nor the special segv handler, but that means
> they will not contain any "dex" files either.
>
>
>
>
> Comment at: source/Plugins/Platform/Android/PlatformAndroid.cpp:399
> +// Define a SIGSEGV that doesn't require any headers
> +#define ANDROID_SIGSEGV 11
> +
>
> I'm not sure if SEGV is one of them, but numbers of some signals vary between
> architectures. You should be able to get the real value via
> process->GetUnixSignals()
>
>
>
> Comment at: source/Plugins/Platform/Android/PlatformAndroid.cpp:424
> + // We are lookking for .dex, .odex, and .oat files.
> + if (ext_ref.endswith("dex") || ext_ref.endswith("oat")) {
> +// We have a SIGSEGV we need to mute
>
> jingham wrote:
>> Given that this is a pretty big behavior change, I would exactly match on
>> the three extensions rather than use endswith, so it only affects the file
>> types you care about.
> Agreed, matching on the exact extension looks safer and more obvious. The
> most llvm-y way of writing that would be
> `StringSwitch(ext.GetStringRef()).Cases("dex", "oat", "odex",
> true).Default(false)`
>
>
> https://reviews.llvm.org/D48177
>
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D48177: Suppress SIGSEGV on Android when the program will recover
jingham added a subscriber: clayborg. jingham added a comment. Thanks for the explanation! Jim https://reviews.llvm.org/D48177 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D48060: Introduce lldb-framework CMake target and centralize its logic
xiaobai updated this revision to Diff 151543.
xiaobai added a comment.
Pavel's suggestions.
https://reviews.llvm.org/D48060
Files:
CMakeLists.txt
cmake/modules/AddLLDB.cmake
cmake/modules/LLDBFramework.cmake
source/API/CMakeLists.txt
tools/driver/CMakeLists.txt
Index: tools/driver/CMakeLists.txt
===
--- tools/driver/CMakeLists.txt
+++ tools/driver/CMakeLists.txt
@@ -24,12 +24,4 @@
add_definitions( -DIMPORT_LIBLLDB )
endif()
-# Add lldb dependency on lldb-server if we can use it.
-if ( LLDB_CAN_USE_LLDB_SERVER )
- add_dependencies(lldb lldb-server)
-endif()
-
-# Add lldb dependency on debugserver if we can use it.
-if ( LLDB_CAN_USE_DEBUGSERVER )
- add_dependencies(lldb debugserver)
-endif()
+add_dependencies(lldb lldb-suite)
Index: source/API/CMakeLists.txt
===
--- source/API/CMakeLists.txt
+++ source/API/CMakeLists.txt
@@ -2,16 +2,6 @@
add_definitions( -DEXPORT_LIBLLDB )
endif()
-option(LLDB_BUILD_FRAMEWORK "Build the Darwin LLDB.framework" Off)
-
-if(LLDB_BUILD_FRAMEWORK AND CMAKE_VERSION VERSION_LESS 3.7)
- message(FATAL_ERROR "LLDB_BUILD_FRAMEWORK is not supported on CMake < 3.7")
-endif()
-
-if (LLDB_BUILD_FRAMEWORK AND NOT APPLE)
- message(FATAL_ERROR "LLDB.framework cannot be generated unless targeting Apple platforms.")
-endif()
-
get_property(LLDB_ALL_PLUGINS GLOBAL PROPERTY LLDB_PLUGINS)
add_lldb_library(liblldb SHARED
@@ -160,47 +150,3 @@
if (LLDB_WRAP_PYTHON)
add_dependencies(liblldb swig_wrapper)
endif()
-
-if(LLDB_BUILD_FRAMEWORK)
- file(GLOB public_headers ${LLDB_SOURCE_DIR}/include/lldb/API/*.h)
- file(GLOB root_public_headers ${LLDB_SOURCE_DIR}/include/lldb/lldb-*.h)
- file(GLOB root_private_headers ${LLDB_SOURCE_DIR}/include/lldb/lldb-private*.h)
- list(REMOVE_ITEM root_public_headers ${root_private_headers})
-
- foreach(header ${public_headers} ${root_public_headers} ${LLDB_SOURCE_DIR}/include/lldb/Utility/SharingPtr.h)
-get_filename_component(basename ${header} NAME)
-add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders/${basename}
- DEPENDS ${header}
- COMMAND ${CMAKE_COMMAND} -E copy ${header} ${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders/${basename})
-list(APPEND framework_headers ${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders/${basename})
- endforeach()
-
- add_custom_target(lldb-framework-headers DEPENDS ${framework_headers}
-COMMAND ${LLDB_SOURCE_DIR}/scripts/framework-header-fix.sh ${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders ${LLDB_VERSION})
- add_dependencies(liblldb lldb-framework-headers)
-
- set_target_properties(liblldb PROPERTIES
-OUTPUT_NAME LLDB
-FRAMEWORK On
-FRAMEWORK_VERSION ${LLDB_FRAMEWORK_VERSION}
-LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/${LLDB_FRAMEWORK_INSTALL_DIR}
-PUBLIC_HEADER "${framework_headers}")
-
- if(NOT IOS)
-if (NOT LLDB_BUILT_STANDALONE)
- add_dependencies(liblldb clang-headers)
-endif()
-add_custom_command(TARGET liblldb POST_BUILD
- COMMAND ${CMAKE_COMMAND} -E copy_directory ${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders $/Headers
- COMMAND ${CMAKE_COMMAND} -E create_symlink Versions/Current/Headers ${CMAKE_BINARY_DIR}/${LLDB_FRAMEWORK_INSTALL_DIR}/LLDB.framework/Headers
- COMMAND ${CMAKE_COMMAND} -E create_symlink ${LLDB_FRAMEWORK_VERSION} ${CMAKE_BINARY_DIR}/${LLDB_FRAMEWORK_INSTALL_DIR}/LLDB.framework/Versions/Current
- COMMAND ${CMAKE_COMMAND} -E copy_directory ${CMAKE_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/clang/${LLDB_VERSION} $/Resources/Clang
- )
- else()
-add_custom_command(TARGET liblldb POST_BUILD
- COMMAND ${CMAKE_COMMAND} -E copy_directory ${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders $/Headers
- )
- endif()
-
-endif()
-
Index: cmake/modules/LLDBFramework.cmake
===
--- /dev/null
+++ cmake/modules/LLDBFramework.cmake
@@ -0,0 +1,44 @@
+file(GLOB public_headers ${LLDB_SOURCE_DIR}/include/lldb/API/*.h)
+file(GLOB root_public_headers ${LLDB_SOURCE_DIR}/include/lldb/lldb-*.h)
+file(GLOB root_private_headers ${LLDB_SOURCE_DIR}/include/lldb/lldb-private*.h)
+list(REMOVE_ITEM root_public_headers ${root_private_headers})
+foreach(header
+${public_headers}
+${root_public_headers}
+${LLDB_SOURCE_DIR}/include/lldb/Utility/SharingPtr.h)
+ get_filename_component(basename ${header} NAME)
+ add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders/${basename}
+ DEPENDS ${header}
+ COMMAND ${CMAKE_COMMAND} -E copy ${header} ${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders/${basename})
+ list(APPEND framework_headers ${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders/${basename})
+endforeach()
+add_custom_target(lldb-framework-headers
+ DEPENDS ${framework_headers}
+ COMMAND ${LLDB_SOURCE_DIR
[Lldb-commits] [PATCH] D48060: Introduce lldb-framework CMake target and centralize its logic
xiaobai added a comment.
I think this is in a pretty good state. I built LLDB.framework with xcodebuild
and compared it. There are still some discrepancies but this brings us a step
closer to a final working solution.
Comment at: cmake/modules/LLDBFramework.cmake:45
+
+ add_dependencies(lldb-framework liblldb lldb-argdumper lldb-server
lldb-framework-headers)
+ add_dependencies(finish_swig lldb-framework)
xiaobai wrote:
> labath wrote:
> > xiaobai wrote:
> > > labath wrote:
> > > > xiaobai wrote:
> > > > > labath wrote:
> > > > > > Maybe lldb-argdumper and lldb-server dependencies should be handled
> > > > > > as a part of INCLUDE_IN_FRAMEWORK argument to add_lldb_executable?
> > > > > > Or do you have other plans for that?
> > > > > One of the goals I had in centralizing the framework generation code
> > > > > would be to centralize and make explicit which tools went into the
> > > > > framework. The idea I had was to get rid of the INCLUDE_IN_FRAMEWORK
> > > > > argument to add_lldb_executable. Since add_lldb_executable builds the
> > > > > binary differently when building for the framework (modifying the
> > > > > rpath, changing the output destination and symlinking it to your
> > > > > build tree's bin dir), it should be sufficient just to check for
> > > > > LLDB_BUILD_FRAMEWORK.
> > > > >
> > > > > What do you think of this?
> > > > Both of the approaches sound reasonable to me. If you want to go this
> > > > way, then I'm fine with that.
> > > I've begun refactoring to remove `INCLUDE_IN_FRAMEWORK` but I've started
> > > thinking about some possibly negative repercussions. I'm wondering what
> > > you think of this:
> > >
> > > `add_lldb_tool` (which invokes `add_lldb_executable`) can be used to add
> > > lldb executables that won't be included in the framework AFAICT (e.g.
> > > lldb-mi). What I was going to do was remove `INCLUDE_IN_FRAMEWORK` option
> > > so that every tool will get put into the framework and symlinked to
> > > `$BUILD_DIR/bin` when you run cmake with `LLDB_BUILD_FRAMEWORK=1`. This
> > > will mean that lldb-mi will be put in the framework if you do something
> > > like `make lldb-mi` after configuring with `LLDB_BUILD_FRAMEWORK=1`.
> > >
> > > In that case, do you think it makes sense to keep `INCLUDE_IN_FRAMEWORK`
> > > as an option and use that to build part of the dependency tree for the
> > > lldb-framework target? Or do you think this is an unlikely enough example
> > > that it shouldn't matter?
> > I think this is an important issue. We shouldn't have our install artifacts
> > depend on what other targets the user happened to build. And it's not just
> > the user typing "make lldb-mi" thats the problem. He can just decide to
> > type "make" to build all targets, and then he'll end up with the same issue.
> >
> > I think it still may be possible to have framework management centralized
> > if you would make the list of targets that go into the framework explicit
> > here. Something like:
> > ```
> > foreach(target in ${TOOLS_THAT_GO_INTO_THE_FRAMEWORK})
> > do_whatever_add_lldb_tool_would_have_done()
> > endforeach()
> > ```
> > But, as I said, I think that keeping this part of the logic inside
> > add_lldb_tool is fine too. If you decide to keep INCLUDE_IN_FRAMEWORK arg,
> > then I think it is natural for the dependency management to be done there
> > too. (Basically, I want to avoid the knowledge of what tools go into the
> > framework to be defined in more than one place).
> I'm going to attempt to make centralization work just because I would like to
> avoid knowledge of what goes into the framework scattered. Thanks for the
> help.
Decided to keep `INCLUDE_IN_FRAMEWORK` as removing it would introduce more
boilerplate and wrapping that works around the problem instead of fixing it.
https://reviews.llvm.org/D48060
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r334860 - Revert "[lldb-mi] Add overload method for setting an error"
Author: apolyakov
Date: Fri Jun 15 13:20:39 2018
New Revision: 334860
URL: http://llvm.org/viewvc/llvm-project?rev=334860&view=rev
Log:
Revert "[lldb-mi] Add overload method for setting an error"
Summary: This reverts commit r334245 because it duplicates
functionality of Status::AsCString used in SBError.
Reviewers: aprantl, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits, ki.stfu
Differential Revision: https://reviews.llvm.org/D48212
Modified:
lldb/trunk/tools/lldb-mi/MICmdBase.cpp
lldb/trunk/tools/lldb-mi/MICmdBase.h
Modified: lldb/trunk/tools/lldb-mi/MICmdBase.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/lldb-mi/MICmdBase.cpp?rev=334860&r1=334859&r2=334860&view=diff
==
--- lldb/trunk/tools/lldb-mi/MICmdBase.cpp (original)
+++ lldb/trunk/tools/lldb-mi/MICmdBase.cpp Fri Jun 15 13:20:39 2018
@@ -214,23 +214,6 @@ void CMICmdBase::SetError(const CMIUtilS
//++
//
-// Details: Short cut function to enter error information into the command's
-// metadata object and set the command's error status.
-// Type:Method.
-// Args:error - (R) Command result description.
-// Return: None.
-// Throws: None.
-//--
-void CMICmdBase::SetError(const lldb::SBError &error) {
- const char *error_cstr = error.GetCString();
- if (error_cstr)
-SetError(error_cstr);
- else
-SetError("unknown error");
-}
-
-//++
-//
// Details: Ask a command to provide its unique identifier.
// Type:Method.
// Args:A unique identifier for this command class.
Modified: lldb/trunk/tools/lldb-mi/MICmdBase.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/lldb-mi/MICmdBase.h?rev=334860&r1=334859&r2=334860&view=diff
==
--- lldb/trunk/tools/lldb-mi/MICmdBase.h (original)
+++ lldb/trunk/tools/lldb-mi/MICmdBase.h Fri Jun 15 13:20:39 2018
@@ -12,8 +12,6 @@
// C Includes
// C++ Includes
// Other libraries and framework includes
-#include "lldb/API/SBError.h"
-
// Project includes
#include "MICmdArgSet.h"
#include "MICmdData.h"
@@ -82,7 +80,6 @@ public:
// Methods:
protected:
void SetError(const CMIUtilString &rErrMsg);
- void SetError(const lldb::SBError &error);
template T *GetOption(const CMIUtilString &vStrOptionName);
bool ParseValidateCmdOptions();
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D48212: Revert "[lldb-mi] Add overload method for setting an error"
This revision was automatically updated to reflect the committed changes.
Closed by commit rL334860: Revert "[lldb-mi] Add overload method for
setting an error" (authored by apolyakov, committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
https://reviews.llvm.org/D48212?vs=151482&id=151553#toc
Repository:
rL LLVM
https://reviews.llvm.org/D48212
Files:
lldb/trunk/tools/lldb-mi/MICmdBase.cpp
lldb/trunk/tools/lldb-mi/MICmdBase.h
Index: lldb/trunk/tools/lldb-mi/MICmdBase.cpp
===
--- lldb/trunk/tools/lldb-mi/MICmdBase.cpp
+++ lldb/trunk/tools/lldb-mi/MICmdBase.cpp
@@ -214,23 +214,6 @@
//++
//
-// Details: Short cut function to enter error information into the command's
-// metadata object and set the command's error status.
-// Type:Method.
-// Args:error - (R) Command result description.
-// Return: None.
-// Throws: None.
-//--
-void CMICmdBase::SetError(const lldb::SBError &error) {
- const char *error_cstr = error.GetCString();
- if (error_cstr)
-SetError(error_cstr);
- else
-SetError("unknown error");
-}
-
-//++
-//
// Details: Ask a command to provide its unique identifier.
// Type:Method.
// Args:A unique identifier for this command class.
Index: lldb/trunk/tools/lldb-mi/MICmdBase.h
===
--- lldb/trunk/tools/lldb-mi/MICmdBase.h
+++ lldb/trunk/tools/lldb-mi/MICmdBase.h
@@ -12,8 +12,6 @@
// C Includes
// C++ Includes
// Other libraries and framework includes
-#include "lldb/API/SBError.h"
-
// Project includes
#include "MICmdArgSet.h"
#include "MICmdData.h"
@@ -82,7 +80,6 @@
// Methods:
protected:
void SetError(const CMIUtilString &rErrMsg);
- void SetError(const lldb::SBError &error);
template T *GetOption(const CMIUtilString &vStrOptionName);
bool ParseValidateCmdOptions();
Index: lldb/trunk/tools/lldb-mi/MICmdBase.cpp
===
--- lldb/trunk/tools/lldb-mi/MICmdBase.cpp
+++ lldb/trunk/tools/lldb-mi/MICmdBase.cpp
@@ -214,23 +214,6 @@
//++
//
-// Details: Short cut function to enter error information into the command's
-// metadata object and set the command's error status.
-// Type:Method.
-// Args:error - (R) Command result description.
-// Return: None.
-// Throws: None.
-//--
-void CMICmdBase::SetError(const lldb::SBError &error) {
- const char *error_cstr = error.GetCString();
- if (error_cstr)
-SetError(error_cstr);
- else
-SetError("unknown error");
-}
-
-//++
-//
// Details: Ask a command to provide its unique identifier.
// Type:Method.
// Args:A unique identifier for this command class.
Index: lldb/trunk/tools/lldb-mi/MICmdBase.h
===
--- lldb/trunk/tools/lldb-mi/MICmdBase.h
+++ lldb/trunk/tools/lldb-mi/MICmdBase.h
@@ -12,8 +12,6 @@
// C Includes
// C++ Includes
// Other libraries and framework includes
-#include "lldb/API/SBError.h"
-
// Project includes
#include "MICmdArgSet.h"
#include "MICmdData.h"
@@ -82,7 +80,6 @@
// Methods:
protected:
void SetError(const CMIUtilString &rErrMsg);
- void SetError(const lldb::SBError &error);
template T *GetOption(const CMIUtilString &vStrOptionName);
bool ParseValidateCmdOptions();
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D48060: Introduce lldb-framework CMake target and centralize its logic
labath added a comment.
This is looking very good, I just have one more quick question. I am wondering
whether we couldn't simplify this dependency management a tad bit more. Would
the thing I'm proposing below work for you?
Comment at: CMakeLists.txt:147-153
+ if (LLDB_CAN_USE_LLDB_SERVER)
+add_dependencies(lldb-suite lldb-server)
+ endif()
+ if (LLDB_CAN_USE_DEBUGSERVER)
+add_dependencies(lldb-suite debugserver)
+ endif()
+ add_dependencies(lldb-suite liblldb lldb-argdumper)
This code here.
Comment at: cmake/modules/AddLLDB.cmake:102-104
if(LLDB_BUILD_FRAMEWORK)
if(ARG_INCLUDE_IN_FRAMEWORK)
+ add_dependencies(lldb-framework ${name})
If you reorder this slightly, then you should be able to get rid of the extra
dependency code in main CMakeLists.txt.
Something like this:
```
if (ARG_INCLUDE_IN_FRAMEWORK)
add_dependencies(lldb-suite ${name})
if (LLDB_BUILD_FRAMEWORK)
...
```
(of course, then the INCLUDE_IN_FRAMEWORK arg will become misnamed, but that
can be solved by renaming it to INCLUDE_IN_SUITE)
https://reviews.llvm.org/D48060
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r334861 - Fix TestExec after r334783
Author: friss Date: Fri Jun 15 13:36:03 2018 New Revision: 334861 URL: http://llvm.org/viewvc/llvm-project?rev=334861&view=rev Log: Fix TestExec after r334783 The second makefile that was added has implicit rules which meant that secondprog.cpp would be built once into a secondprog binary, but it would also be compiled as a.out overwriting the main binary. This lead to spurious failures. This commit simplifies the Makefile to build only once with the correct executable name. Modified: lldb/trunk/packages/Python/lldbsuite/test/functionalities/exec/secondprog.mk Modified: lldb/trunk/packages/Python/lldbsuite/test/functionalities/exec/secondprog.mk URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/exec/secondprog.mk?rev=334861&r1=334860&r2=334861&view=diff == --- lldb/trunk/packages/Python/lldbsuite/test/functionalities/exec/secondprog.mk (original) +++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/exec/secondprog.mk Fri Jun 15 13:36:03 2018 @@ -1,13 +1,6 @@ LEVEL = ../../make CXX_SOURCES := secondprog.cpp - -all: secondprog - -secondprog: - $(CXX) $(CXXFLAGS) -o secondprog $(SRCDIR)/secondprog.cpp - -clean:: - rm -rf secondprog secondprog.dSYM +EXE = secondprog include $(LEVEL)/Makefile.rules ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D47992: [lldb-mi] Correct error processing in exec-next command.
apolyakov added a comment. If you look at `bool CMICmdCmdExecContinue::Execute()`, you'll see that there are cases in which we need a flexible way to finish MI command(specific action in error case for example). We have a few options: not to add such an utility function, add and use it in simple situations where we just want to check on SBError status or we may create utility function with lambda functions in which user could specify actions he needs. What are your thoughts about this? https://reviews.llvm.org/D47992 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D48060: Introduce lldb-framework CMake target and centralize its logic
xiaobai added a comment.
xiaobai added inline comments.
Comment at: cmake/modules/AddLLDB.cmake:102-104
if(LLDB_BUILD_FRAMEWORK)
if(ARG_INCLUDE_IN_FRAMEWORK)
+ add_dependencies(lldb-framework ${name})
labath wrote:
> If you reorder this slightly, then you should be able to get rid of the extra
> dependency code in main CMakeLists.txt.
> Something like this:
> ```
> if (ARG_INCLUDE_IN_FRAMEWORK)
> add_dependencies(lldb-suite ${name})
> if (LLDB_BUILD_FRAMEWORK)
> ...
> ```
>
> (of course, then the INCLUDE_IN_FRAMEWORK arg will become misnamed, but that
> can be solved by renaming it to INCLUDE_IN_SUITE)
This is a pretty good idea imo. I think it'll make the dependency tracking much
easier. The lldb-framework target then becomes a small target.
https://reviews.llvm.org/D48060
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D44603: [lldb] Introduce StackFrameRecognizer
kubamracek added a comment. In https://reviews.llvm.org/D44603#1133149, @jingham wrote: > This is going as I imagined it should, looks great! > We probably want to turn this on by default for "frame var" or no one will > ever discover it. The IDE folks can decide on their own what to do from the > SB API's. Since you are doing module filtering and this only triggers when > you explicitly run "frame var" I think having it on by default will not be a > big deal. > Does this work with "frame var paths" as well? That is, if I do: It does not work. The reason is that the current patch is not creating VariableSP objects, so things like m_variable_list_sp (in StackFrame) don't contain these new "recognized arguments". Right now, I'm just creating ValueObjects and GetVariableList/GetInScopeVariableList doesn't know about them. Do you think we should go that way instead? In that case I think we'd need to extend or subclass Variable so that we can actually create Variable objects that are not backed by DWARF and SymbolContextScope and stuff like that. If you think that makes sense, I'll be happy to work on that. Also, if you think it's not necessary for an initial commit, I can send a separate follow-up patch (to avoid growing this already large patch). https://reviews.llvm.org/D44603 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r334872 - Sort the files in the PBXBuildFile and PBXFileReference
Author: jmolenda Date: Fri Jun 15 16:29:32 2018 New Revision: 334872 URL: http://llvm.org/viewvc/llvm-project?rev=334872&view=rev Log: Sort the files in the PBXBuildFile and PBXFileReference sections of lldb's xcode project file to reduce automerger issues with the github swift repository of lldb where the order of these entries has drifted significantly over the years. Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r334873 - Sort the files in the PBXBuildFile and PBXFileReference sections
Author: jmolenda
Date: Fri Jun 15 16:32:37 2018
New Revision: 334873
URL: http://llvm.org/viewvc/llvm-project?rev=334873&view=rev
Log:
Sort the files in the PBXBuildFile and PBXFileReference sections
of debugserver's xcode project file to reduce automerger issues
with the github swift repository of lldb where the order of these
entries has drifted significantly over the years.
Modified:
lldb/trunk/tools/debugserver/debugserver.xcodeproj/project.pbxproj
Modified: lldb/trunk/tools/debugserver/debugserver.xcodeproj/project.pbxproj
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/debugserver/debugserver.xcodeproj/project.pbxproj?rev=334873&r1=334872&r2=334873&view=diff
==
--- lldb/trunk/tools/debugserver/debugserver.xcodeproj/project.pbxproj
(original)
+++ lldb/trunk/tools/debugserver/debugserver.xcodeproj/project.pbxproj Fri Jun
15 16:32:37 2018
@@ -7,167 +7,131 @@
objects = {
/* Begin PBXBuildFile section */
- 23043C9D1D35DBEC00FC25CA /* JSON.cpp in Sources */ = {isa =
PBXBuildFile; fileRef = 233B4EA51D2DB54300E98261 /* JSON.cpp */; };
- 23043C9E1D35DBFA00FC25CA /* StringConvert.cpp in Sources */ =
{isa = PBXBuildFile; fileRef = 233B4EA81D2DB96A00E98261 /* StringConvert.cpp
*/; };
- 2307CCCB1D4A5D630016ABC0 /* LogFilterExactMatch.cpp in Sources
*/ = {isa = PBXBuildFile; fileRef = 237821AE1D4917D20028B7A1 /*
LogFilterExactMatch.cpp */; };
- 233B4EA71D2DB54300E98261 /* JSON.cpp in Sources */ = {isa =
PBXBuildFile; fileRef = 233B4EA51D2DB54300E98261 /* JSON.cpp */; };
- 233B4EA91D2DB96A00E98261 /* StringConvert.cpp in Sources */ =
{isa = PBXBuildFile; fileRef = 233B4EA81D2DB96A00E98261 /* StringConvert.cpp
*/; };
- 23562ED21D3424DF00AB2BD4 /* LogMessageOsLog.cpp in Sources */ =
{isa = PBXBuildFile; fileRef = 23562ED01D3424DF00AB2BD4 /* LogMessageOsLog.cpp
*/; };
- 23562ED31D3424DF00AB2BD4 /* LogMessageOsLog.cpp in Sources */ =
{isa = PBXBuildFile; fileRef = 23562ED01D3424DF00AB2BD4 /* LogMessageOsLog.cpp
*/; };
23562ED61D342A5A00AB2BD4 /* ActivityStore.cpp in Sources */ =
{isa = PBXBuildFile; fileRef = 23562ED51D342A5A00AB2BD4 /* ActivityStore.cpp
*/; };
23562ED71D342A5A00AB2BD4 /* ActivityStore.cpp in Sources */ =
{isa = PBXBuildFile; fileRef = 23562ED51D342A5A00AB2BD4 /* ActivityStore.cpp
*/; };
- 23562ED91D342BAB2BD4 /* LogMessage.cpp in Sources */ = {isa
= PBXBuildFile; fileRef = 23562ED81D342BAB2BD4 /* LogMessage.cpp */; };
- 23562EDA1D342BAB2BD4 /* LogMessage.cpp in Sources */ = {isa
= PBXBuildFile; fileRef = 23562ED81D342BAB2BD4 /* LogMessage.cpp */; };
- 237821B01D4917D20028B7A1 /* LogFilterExactMatch.cpp in Sources
*/ = {isa = PBXBuildFile; fileRef = 237821AE1D4917D20028B7A1 /*
LogFilterExactMatch.cpp */; };
+ 26CE05C5115C36590022F371 /* CFBundle.cpp in Sources */ = {isa =
PBXBuildFile; fileRef = 2695DD910D3EBFF6007E4CA2 /* CFBundle.cpp */; };
+ 456F67641AD46CE9002850C2 /* CFBundle.cpp in Sources */ = {isa =
PBXBuildFile; fileRef = 2695DD910D3EBFF6007E4CA2 /* CFBundle.cpp */; };
+ 26CE05C3115C36580022F371 /* CFString.cpp in Sources */ = {isa =
PBXBuildFile; fileRef = 2695DD9B0D3EC160007E4CA2 /* CFString.cpp */; };
+ 456F67621AD46CE9002850C2 /* CFString.cpp in Sources */ = {isa =
PBXBuildFile; fileRef = 2695DD9B0D3EC160007E4CA2 /* CFString.cpp */; };
+ 26CE05CF115C36F70022F371 /* CoreFoundation.framework in
Frameworks */ = {isa = PBXBuildFile; fileRef = 26ACA3340D3E956300A2120B /*
CoreFoundation.framework */; settings = {ATTRIBUTES = (Required, ); }; };
+ 456F676B1AD46CE9002850C2 /* CoreFoundation.framework in
Frameworks */ = {isa = PBXBuildFile; fileRef = 26ACA3340D3E956300A2120B /*
CoreFoundation.framework */; settings = {ATTRIBUTES = (Required, ); }; };
+ 26CE05B7115C363B0022F371 /* DNB.cpp in Sources */ = {isa =
PBXBuildFile; fileRef = 26C637D60C71334A0024798E /* DNB.cpp */; };
+ 456F67551AD46CE9002850C2 /* DNB.cpp in Sources */ = {isa =
PBXBuildFile; fileRef = 26C637D60C71334A0024798E /* DNB.cpp */; };
+ 264D5D581293835600ED4C01 /* DNBArch.cpp in Sources */ = {isa =
PBXBuildFile; fileRef = 264D5D571293835600ED4C01 /* DNBArch.cpp */; };
+ 456F67671AD46CE9002850C2 /* DNBArch.cpp in Sources */ = {isa =
PBXBuildFile; fileRef = 264D5D571293835600ED4C01 /* DNBArch.cpp */; };
+ 26CE05C1115C36510022F371 /* DNBArchImpl.cpp in Sources */ =
{isa = PBXBuildFile; fileRef = 2675D4220CCEB705000F49AF /* DNBArchImpl.cpp */;
};
+ 26CE05C2115C36550022F371 /* DNBArchImpl.cpp in Sources */ =
{isa = PBXBuildFile; fileRef = 26C637FB0C71334A0024798E /* DNBArchImpl.cpp */;
};
+ 456F67601AD46CE9002850C2 /* DNBArchImpl.cp
[Lldb-commits] [PATCH] D48060: Introduce lldb-framework CMake target and centralize its logic
xiaobai updated this revision to Diff 151598.
xiaobai added a comment.
Labath's suggestion
https://reviews.llvm.org/D48060
Files:
CMakeLists.txt
cmake/modules/AddLLDB.cmake
cmake/modules/LLDBFramework.cmake
source/API/CMakeLists.txt
tools/argdumper/CMakeLists.txt
tools/darwin-debug/CMakeLists.txt
tools/debugserver/source/CMakeLists.txt
tools/driver/CMakeLists.txt
tools/lldb-server/CMakeLists.txt
Index: tools/lldb-server/CMakeLists.txt
===
--- tools/lldb-server/CMakeLists.txt
+++ tools/lldb-server/CMakeLists.txt
@@ -42,7 +42,7 @@
list(APPEND LLDB_PLUGINS lldbPluginObjectFileELF)
endif()
-add_lldb_tool(lldb-server INCLUDE_IN_FRAMEWORK
+add_lldb_tool(lldb-server INCLUDE_IN_SUITE
Acceptor.cpp
lldb-gdbserver.cpp
lldb-platform.cpp
Index: tools/driver/CMakeLists.txt
===
--- tools/driver/CMakeLists.txt
+++ tools/driver/CMakeLists.txt
@@ -24,12 +24,4 @@
add_definitions( -DIMPORT_LIBLLDB )
endif()
-# Add lldb dependency on lldb-server if we can use it.
-if ( LLDB_CAN_USE_LLDB_SERVER )
- add_dependencies(lldb lldb-server)
-endif()
-
-# Add lldb dependency on debugserver if we can use it.
-if ( LLDB_CAN_USE_DEBUGSERVER )
- add_dependencies(lldb debugserver)
-endif()
+add_dependencies(lldb lldb-suite)
Index: tools/debugserver/source/CMakeLists.txt
===
--- tools/debugserver/source/CMakeLists.txt
+++ tools/debugserver/source/CMakeLists.txt
@@ -161,7 +161,7 @@
COMPILE_DEFINITIONS HAVE_LIBCOMPRESSION)
endif()
set(LLVM_OPTIONAL_SOURCES ${lldbDebugserverCommonSources})
- add_lldb_tool(debugserver INCLUDE_IN_FRAMEWORK
+ add_lldb_tool(debugserver INCLUDE_IN_SUITE
debugserver.cpp
LINK_LIBS
Index: tools/darwin-debug/CMakeLists.txt
===
--- tools/darwin-debug/CMakeLists.txt
+++ tools/darwin-debug/CMakeLists.txt
@@ -1,3 +1,3 @@
-add_lldb_tool(darwin-debug INCLUDE_IN_FRAMEWORK
+add_lldb_tool(darwin-debug INCLUDE_IN_SUITE
darwin-debug.cpp
)
Index: tools/argdumper/CMakeLists.txt
===
--- tools/argdumper/CMakeLists.txt
+++ tools/argdumper/CMakeLists.txt
@@ -1,4 +1,4 @@
-add_lldb_tool(lldb-argdumper INCLUDE_IN_FRAMEWORK
+add_lldb_tool(lldb-argdumper INCLUDE_IN_SUITE
argdumper.cpp
LINK_LIBS
Index: source/API/CMakeLists.txt
===
--- source/API/CMakeLists.txt
+++ source/API/CMakeLists.txt
@@ -2,16 +2,6 @@
add_definitions( -DEXPORT_LIBLLDB )
endif()
-option(LLDB_BUILD_FRAMEWORK "Build the Darwin LLDB.framework" Off)
-
-if(LLDB_BUILD_FRAMEWORK AND CMAKE_VERSION VERSION_LESS 3.7)
- message(FATAL_ERROR "LLDB_BUILD_FRAMEWORK is not supported on CMake < 3.7")
-endif()
-
-if (LLDB_BUILD_FRAMEWORK AND NOT APPLE)
- message(FATAL_ERROR "LLDB.framework cannot be generated unless targeting Apple platforms.")
-endif()
-
get_property(LLDB_ALL_PLUGINS GLOBAL PROPERTY LLDB_PLUGINS)
add_lldb_library(liblldb SHARED
@@ -159,47 +149,3 @@
if (LLDB_WRAP_PYTHON)
add_dependencies(liblldb swig_wrapper)
endif()
-
-if(LLDB_BUILD_FRAMEWORK)
- file(GLOB public_headers ${LLDB_SOURCE_DIR}/include/lldb/API/*.h)
- file(GLOB root_public_headers ${LLDB_SOURCE_DIR}/include/lldb/lldb-*.h)
- file(GLOB root_private_headers ${LLDB_SOURCE_DIR}/include/lldb/lldb-private*.h)
- list(REMOVE_ITEM root_public_headers ${root_private_headers})
-
- foreach(header ${public_headers} ${root_public_headers} ${LLDB_SOURCE_DIR}/include/lldb/Utility/SharingPtr.h)
-get_filename_component(basename ${header} NAME)
-add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders/${basename}
- DEPENDS ${header}
- COMMAND ${CMAKE_COMMAND} -E copy ${header} ${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders/${basename})
-list(APPEND framework_headers ${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders/${basename})
- endforeach()
-
- add_custom_target(lldb-framework-headers DEPENDS ${framework_headers}
-COMMAND ${LLDB_SOURCE_DIR}/scripts/framework-header-fix.sh ${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders ${LLDB_VERSION})
- add_dependencies(liblldb lldb-framework-headers)
-
- set_target_properties(liblldb PROPERTIES
-OUTPUT_NAME LLDB
-FRAMEWORK On
-FRAMEWORK_VERSION ${LLDB_FRAMEWORK_VERSION}
-LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/${LLDB_FRAMEWORK_INSTALL_DIR}
-PUBLIC_HEADER "${framework_headers}")
-
- if(NOT IOS)
-if (NOT LLDB_BUILT_STANDALONE)
- add_dependencies(liblldb clang-headers)
-endif()
-add_custom_command(TARGET liblldb POST_BUILD
- COMMAND ${CMAKE_COMMAND} -E copy_directory ${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders $/Headers
- COMMAND ${CMAKE_COMMAND} -E create_syml
