[Lldb-commits] [lldb] r274116 - XFAIL tests which fail with gcc on linux
Author: labath Date: Wed Jun 29 05:16:14 2016 New Revision: 274116 URL: http://llvm.org/viewvc/llvm-project?rev=274116&view=rev Log: XFAIL tests which fail with gcc on linux Modified: lldb/trunk/packages/Python/lldbsuite/test/expression_command/top-level/TestTopLevelExprs.py lldb/trunk/packages/Python/lldbsuite/test/lang/c/register_variables/TestRegisterVariables.py lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/template/TestTemplateIntegerArgs.py Modified: lldb/trunk/packages/Python/lldbsuite/test/expression_command/top-level/TestTopLevelExprs.py URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/expression_command/top-level/TestTopLevelExprs.py?rev=274116&r1=274115&r2=274116&view=diff == --- lldb/trunk/packages/Python/lldbsuite/test/expression_command/top-level/TestTopLevelExprs.py (original) +++ lldb/trunk/packages/Python/lldbsuite/test/expression_command/top-level/TestTopLevelExprs.py Wed Jun 29 05:16:14 2016 @@ -52,6 +52,7 @@ class TopLevelExpressionsTestCase(TestBa @add_test_categories(['pyapi']) @expectedFailureAndroid(api_levels=[21, 22], bugnumber="llvm.org/pr27787") @expectedFailureAll(oslist=["linux"], archs=["arm", "aarch64"], bugnumber="llvm.org/pr27787") +@expectedFailureAll(bugnumber="llvm.org/pr28353", oslist=["linux"], archs=["i386", "x86_64"], compiler="gcc", compiler_version=["<", "4.9"]) @skipIf(debug_info="gmodules") # not relevant @skipIf(oslist=["windows"]) # Error in record layout on Windows def test_top_level_expressions(self): Modified: lldb/trunk/packages/Python/lldbsuite/test/lang/c/register_variables/TestRegisterVariables.py URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/c/register_variables/TestRegisterVariables.py?rev=274116&r1=274115&r2=274116&view=diff == --- lldb/trunk/packages/Python/lldbsuite/test/lang/c/register_variables/TestRegisterVariables.py (original) +++ lldb/trunk/packages/Python/lldbsuite/test/lang/c/register_variables/TestRegisterVariables.py Wed Jun 29 05:16:14 2016 @@ -92,7 +92,7 @@ class RegisterVariableTestCase(TestBase) @expectedFailureAll(compiler="clang", compiler_version=['<', '3.5']) -@expectedFailureAll(compiler="gcc", compiler_version=['>=', '4.8.2'], archs="i386") +@expectedFailureAll(compiler="gcc", compiler_version=['>=', '4.8.2'], archs=["i386", "x86_64"]) def test_and_run_command(self): """Test expressions on register values.""" Modified: lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/template/TestTemplateIntegerArgs.py URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/template/TestTemplateIntegerArgs.py?rev=274116&r1=274115&r2=274116&view=diff == --- lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/template/TestTemplateIntegerArgs.py (original) +++ lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/template/TestTemplateIntegerArgs.py Wed Jun 29 05:16:14 2016 @@ -10,6 +10,7 @@ class TemplateIntegerArgsTestCase(TestBa mydir = TestBase.compute_mydir(__file__) +@expectedFailureAll(bugnumber="llvm.org/pr28354", compiler="gcc", oslist=["linux"]) def test_with_run_command(self): """Test that C++ template classes that have integer parameters work correctly. ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D20464: [LLDB][MIPS] Check if libatomic needs to be specified explicitly.
labath accepted this revision. labath added a comment. This revision is now accepted and ready to land. lgtm, thanks. Repository: rL LLVM http://reviews.llvm.org/D20464 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D21770: Improve ADB utilization within Android platform
labath added a comment. Is AdbClient getting big enough to deserve a couple of unit tests? All it would take is to add the ability to specify the address to connect to and make a small mock server that listens at that address? http://reviews.llvm.org/D21770 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D21751: Implement GetMemoryRegions() for Linux and Mac OSX core files.
labath added a subscriber: labath. labath added a comment. Please also add a test for this in `TestLinuxCore.py`. There shouldn't be a need to add a new core file, you can just add an additional check to the `do_test` method that verifies the right memory regions (which you can pass in the same way as the pid). You can pass in bogus (empty) values for the i386 and s390x test cases, as they are not working now anyway. http://reviews.llvm.org/D21751 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r274121 - [LLDB][MIPS] Check if libatomic needs to be specified explicitly
Author: slthakur Date: Wed Jun 29 07:30:18 2016 New Revision: 274121 URL: http://llvm.org/viewvc/llvm-project?rev=274121&view=rev Log: [LLDB][MIPS] Check if libatomic needs to be specified explicitly Patch by Nitesh Jain. Summary : The problem appears while linking liblldb.so. The class Address contain atomic variable m_offset. The loading and storing of variable is access via atomic_load_8 and atomic_store_8 functions. Some target fail to implicitly link libatomic, which cause undefine reference to atomic_store_8/atomic_load_8. This patch uses http://reviews.llvm.org/D20896 to check if libatomic need to be explicitly link. Reviewed by labath. Differential: D20464 Modified: lldb/trunk/cmake/LLDBDependencies.cmake Modified: lldb/trunk/cmake/LLDBDependencies.cmake URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/cmake/LLDBDependencies.cmake?rev=274121&r1=274120&r2=274121&view=diff == --- lldb/trunk/cmake/LLDBDependencies.cmake (original) +++ lldb/trunk/cmake/LLDBDependencies.cmake Wed Jun 29 07:30:18 2016 @@ -157,6 +157,11 @@ if (NOT CMAKE_SYSTEM_NAME MATCHES "Windo endif() endif() endif() + +if (NOT HAVE_CXX_ATOMICS64_WITHOUT_LIB ) +list(APPEND LLDB_SYSTEM_LIBS atomic) +endif() + # On FreeBSD/NetBSD backtrace() is provided by libexecinfo, not libc. if (CMAKE_SYSTEM_NAME MATCHES "FreeBSD" OR CMAKE_SYSTEM_NAME MATCHES "NetBSD") list(APPEND LLDB_SYSTEM_LIBS execinfo) ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r274125 - Remove platform plugins from lldb-server
Author: labath Date: Wed Jun 29 08:58:27 2016 New Revision: 274125 URL: http://llvm.org/viewvc/llvm-project?rev=274125&view=rev Log: Remove platform plugins from lldb-server Summary: This removes the last usage of Platform plugins in lldb-server -- it was used for launching child processes, where it can be trivially replaced by Host::LaunchProces (as lldb-server is always running on the host). Removing platform plugins enables us to remove a lot of other unused code, which was pulled in as a transitive dependency, and it reduces lldb-server size by 4%--9% (depending on build type and architecture). Reviewers: clayborg Subscribers: tberghammer, danalbert, srhines, lldb-commits Differential Revision: http://reviews.llvm.org/D20440 Modified: lldb/trunk/source/API/SystemInitializerFull.cpp lldb/trunk/source/Initialization/SystemInitializerCommon.cpp lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerPlatform.cpp lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerPlatform.h lldb/trunk/tools/lldb-server/lldb-gdbserver.cpp Modified: lldb/trunk/source/API/SystemInitializerFull.cpp URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/source/API/SystemInitializerFull.cpp?rev=274125&r1=274124&r2=274125&view=diff == --- lldb/trunk/source/API/SystemInitializerFull.cpp (original) +++ lldb/trunk/source/API/SystemInitializerFull.cpp Wed Jun 29 08:58:27 2016 @@ -42,9 +42,9 @@ #include "Plugins/ABI/SysV-s390x/ABISysV_s390x.h" #include "Plugins/ABI/SysV-x86_64/ABISysV_x86_64.h" #include "Plugins/Disassembler/llvm/DisassemblerLLVMC.h" -#include "Plugins/DynamicLoader/Static/DynamicLoaderStatic.h" #include "Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderMacOSXDYLD.h" #include "Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.h" +#include "Plugins/DynamicLoader/Static/DynamicLoaderStatic.h" #include "Plugins/DynamicLoader/Windows-DYLD/DynamicLoaderWindowsDYLD.h" #include "Plugins/Instruction/ARM64/EmulateInstructionARM64.h" #include "Plugins/InstrumentationRuntime/AddressSanitizer/AddressSanitizerRuntime.h" @@ -62,8 +62,16 @@ #include "Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.h" #include "Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.h" #include "Plugins/MemoryHistory/asan/MemoryHistoryASan.h" -#include "Plugins/OperatingSystem/Python/OperatingSystemPython.h" #include "Plugins/OperatingSystem/Go/OperatingSystemGo.h" +#include "Plugins/OperatingSystem/Python/OperatingSystemPython.h" +#include "Plugins/Platform/Android/PlatformAndroid.h" +#include "Plugins/Platform/FreeBSD/PlatformFreeBSD.h" +#include "Plugins/Platform/Kalimba/PlatformKalimba.h" +#include "Plugins/Platform/Linux/PlatformLinux.h" +#include "Plugins/Platform/MacOSX/PlatformMacOSX.h" +#include "Plugins/Platform/MacOSX/PlatformRemoteiOS.h" +#include "Plugins/Platform/NetBSD/PlatformNetBSD.h" +#include "Plugins/Platform/Windows/PlatformWindows.h" #include "Plugins/Platform/gdb-server/PlatformRemoteGDBServer.h" #include "Plugins/Process/elf-core/ProcessElfCore.h" #include "Plugins/Process/gdb-remote/ProcessGDBRemote.h" @@ -78,14 +86,16 @@ #include "Plugins/UnwindAssembly/x86/UnwindAssembly-x86.h" #if defined(__APPLE__) -#include "Plugins/Process/mach-core/ProcessMachCore.h" -#include "Plugins/Process/MacOSX-Kernel/ProcessKDP.h" -#include "Plugins/SymbolVendor/MacOSX/SymbolVendorMacOSX.h" +#include "Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.h" #include "Plugins/Platform/MacOSX/PlatformAppleTVSimulator.h" #include "Plugins/Platform/MacOSX/PlatformAppleWatchSimulator.h" +#include "Plugins/Platform/MacOSX/PlatformDarwinKernel.h" #include "Plugins/Platform/MacOSX/PlatformRemoteAppleTV.h" #include "Plugins/Platform/MacOSX/PlatformRemoteAppleWatch.h" -#include "Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.h" +#include "Plugins/Platform/MacOSX/PlatformiOSSimulator.h" +#include "Plugins/Process/MacOSX-Kernel/ProcessKDP.h" +#include "Plugins/Process/mach-core/ProcessMachCore.h" +#include "Plugins/SymbolVendor/MacOSX/SymbolVendorMacOSX.h" #endif #if defined(__FreeBSD__) @@ -281,6 +291,19 @@ SystemInitializerFull::Initialize() ScriptInterpreterPython::Initialize(); #endif +platform_freebsd::PlatformFreeBSD::Initialize(); +platform_linux::PlatformLinux::Initialize(); +platform_netbsd::PlatformNetBSD::Initialize(); +PlatformWindows::Initialize(); +PlatformKalimba::Initialize(); +platform_android::PlatformAndroid::Initialize(); +PlatformRemoteiOS::Initialize(); +PlatformMacOSX::Initialize(); +#if defined(__APPLE__) +PlatformiOSSimulator::Initialize(); +PlatformDarwinKernel::Initialize(); +#e
Re: [Lldb-commits] [PATCH] D20440: Remove platform plugins from lldb-server
This revision was automatically updated to reflect the committed changes.
Closed by commit rL274125: Remove platform plugins from lldb-server (authored
by labath).
Changed prior to commit:
http://reviews.llvm.org/D20440?vs=57807&id=62220#toc
Repository:
rL LLVM
http://reviews.llvm.org/D20440
Files:
lldb/trunk/source/API/SystemInitializerFull.cpp
lldb/trunk/source/Initialization/SystemInitializerCommon.cpp
lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerPlatform.cpp
lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerPlatform.h
lldb/trunk/tools/lldb-server/lldb-gdbserver.cpp
Index: lldb/trunk/tools/lldb-server/lldb-gdbserver.cpp
===
--- lldb/trunk/tools/lldb-server/lldb-gdbserver.cpp
+++ lldb/trunk/tools/lldb-server/lldb-gdbserver.cpp
@@ -32,7 +32,6 @@
#include "lldb/Host/Pipe.h"
#include "lldb/Host/Socket.h"
#include "lldb/Host/StringConvert.h"
-#include "lldb/Target/Platform.h"
#include "Acceptor.h"
#include "LLDBServerUtilities.h"
#include "Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h"
@@ -62,7 +61,6 @@
static struct option g_long_options[] =
{
{ "debug", no_argument,&g_debug, 1 },
-{ "platform", required_argument, NULL, 'p' },
{ "verbose",no_argument,&g_verbose, 1 },
{ "log-file", required_argument, NULL, 'l' },
{ "log-channels", required_argument, NULL, 'c' },
@@ -121,7 +119,6 @@
fprintf(stderr, "Usage:\n %s %s "
"[--log-file log-file-name] "
"[--log-channels log-channel-list] "
-"[--platform platform_name] "
"[--setsid] "
"[--named-pipe named-pipe-path] "
"[--native-regs] "
@@ -131,66 +128,6 @@
exit(0);
}
-static void
-dump_available_platforms (FILE *output_file)
-{
-fprintf (output_file, "Available platform plugins:\n");
-for (int i = 0; ; ++i)
-{
-const char *plugin_name = PluginManager::GetPlatformPluginNameAtIndex (i);
-const char *plugin_desc = PluginManager::GetPlatformPluginDescriptionAtIndex (i);
-
-if (!plugin_name || !plugin_desc)
-break;
-
-fprintf (output_file, "%s\t%s\n", plugin_name, plugin_desc);
-}
-
-if ( Platform::GetHostPlatform () )
-{
-// add this since the default platform doesn't necessarily get registered by
-// the plugin name (e.g. 'host' doesn't show up as a
-// registered platform plugin even though it's the default).
-fprintf (output_file, "%s\tDefault platform for this host.\n", Platform::GetHostPlatform ()->GetPluginName ().AsCString ());
-}
-}
-
-static lldb::PlatformSP
-setup_platform (const std::string &platform_name)
-{
-lldb::PlatformSP platform_sp;
-
-if (platform_name.empty())
-{
-printf ("using the default platform: ");
-platform_sp = Platform::GetHostPlatform ();
-printf ("%s\n", platform_sp->GetPluginName ().AsCString ());
-return platform_sp;
-}
-
-Error error;
-platform_sp = Platform::Create (lldb_private::ConstString(platform_name), error);
-if (error.Fail ())
-{
-// the host platform isn't registered with that name (at
-// least, not always. Check if the given name matches
-// the default platform name. If so, use it.
-if ( Platform::GetHostPlatform () && ( Platform::GetHostPlatform ()->GetPluginName () == ConstString (platform_name.c_str()) ) )
-{
-platform_sp = Platform::GetHostPlatform ();
-}
-else
-{
-fprintf (stderr, "error: failed to create platform with name '%s'\n", platform_name.c_str());
-dump_available_platforms (stderr);
-exit (1);
-}
-}
-printf ("using platform: %s\n", platform_name.c_str ());
-
-return platform_sp;
-}
-
void
handle_attach_to_pid (GDBRemoteCommunicationServerLLGS &gdb_server, lldb::pid_t pid)
{
@@ -421,7 +358,6 @@
argv++;
int long_option_index = 0;
int ch;
-std::string platform_name;
std::string attach_target;
std::string named_pipe_path;
std::string log_file;
@@ -460,11 +396,6 @@
log_channels = StringRef(optarg);
break;
-case 'p': // platform name
-if (optarg && optarg[0])
-platform_name = optarg;
-break;
-
case 'N': // named pipe
if (optarg && optarg[0])
named_pipe_path = optarg;
@@ -548,10 +479,7 @@
exit(255);
}
-// Setup the platform that GDBRemoteCommunicationServerLLGS will use.
-lldb::
Re: [Lldb-commits] [PATCH] D21770: Improve ADB utilization within Android platform
ovyalov added a comment. In http://reviews.llvm.org/D21770#469876, @labath wrote: > Is AdbClient getting big enough to deserve a couple of unit tests? All it > would take is to add the ability to specify the address to connect to and > make a small mock server that listens at that address? It makes sense to do - presumably it might be a non-trivial change but worth doing as a long-term investment. http://reviews.llvm.org/D21770 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D21751: Implement GetMemoryRegions() for Linux and Mac OSX core files.
hhellyer added a comment. In http://reviews.llvm.org/D21751#468976, @clayborg wrote: > We should document the Process::GetMemoryRegionInfo() and what we expect of > it so that all plug-ins implement it correctly. I'll add a full comment in Process.h and I'll make sure the description matches the behaviour of qMemoryRegionInfo. > > I will push a revision which follows the approach you suggest, if we find > > that throws up it’s own problems then I can always revert. As I mentioned > > the remote connections should (hopefully) all work with that pattern so > > GetMemoryRegions implemented in fewer commits with that approach. > > > Indeed. Since we already expect a behavior from > Process::GetMemoryRegionInfo(), I would say lets enforce these requirements > by making Process::GetMemoryRegions() just use that API as required. The only > time we should see an error from Process::GetMemoryRegionInfo() is when it > isn't implemented. Ok, I’ve looked at the implementation on a couple of Mac and Linux cores, at the moment it will return an error if the function is unimplemented or you request a load_addr past the last mapped memory range. After the change it will only return an error when unimplemented. As GetMemoryRegionInfo (on Mac and Linux cores) doesn't return an error if you ask for unmapped memory ranges in the middle of the address space this is probably more consistent as the MemoryRange will always be populated for any address that’s queried, there's nothing magic about addresses beyond the last mapped region it should behave the same for those. I’ll go through and check the behaviour elsewhere and update the patch. I will have to update the existing implementations to set the flag that says whether a memory region is mapped or not but that doesn't look complicated. > > Is PAGEZERO actually included in Mac core dumps? I can see it as load > > command 0 when I run otool against an executable but when I look at a core > > dump from the same executable the first load command looks like load > > command 1 in the executable. There doesn’t seem to be a load command in the > > core for address 0. I might just be missing an flag on otool though. > > > It might not be, but that brings up another thing I was thinking of is that > we could start supplementing the Process::GetMemoryRegionInfo() info by also > looking in any sections that were found in core file memory that might not be > fully described by the core file itself. There is no requirements that if two > sections are adjacent in a core file that they show up as different mapped > regions, so you might find a mapped section of memory from 0x1000-0x8000 that > is actually 0x1000-0x4000 for ".data" and 0x4000-0x8000 that is ".bss". The > memory region was mapped read+write, but would it be nice to know about these > different regions separately? We don't need to do this now, but this is one > place where we could figure out that 0x0-0x1 is __PAGEZERO even > though it isn't mapped into the current mach-o file's memory regions. Also > there are different makers of core files: lldb, the kernel, possibly others. > They don't always follow the same rules when making mach-o core files. So it > is nice to be flexible. Another possibility, instead of splitting regions, is providing a way to iterate over all the sections a region contains. I'm not sure which is better. Do you want me to add a "backed" flag, possibly just for cores, that identifies whether there is any data for this region actually in the core dump. (For example a core might be truncated because of a ulimit or have omitted regions because of /proc/[pid]/coredump_filter settings on Linux.) In http://reviews.llvm.org/D21751#469903, @labath wrote: > Please also add a test for this in `TestLinuxCore.py`. > > There shouldn't be a need to add a new core file, you can just add an > additional check to the `do_test` method that verifies the right memory > regions (which you can pass in the same way as the pid). You can pass in > bogus (empty) values for the i386 and s390x test cases, as they are not > working now anyway. Ok, I'll add that into this patch unless you prefer test updates as separate commits. http://reviews.llvm.org/D21751 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r274159 - Validate the option index before trying to access an array element using it - OptionArgElement can potentially use negative indices to mean interesting, but non option,
Author: enrico
Date: Wed Jun 29 15:23:03 2016
New Revision: 274159
URL: http://llvm.org/viewvc/llvm-project?rev=274159&view=rev
Log:
Validate the option index before trying to access an array element using it -
OptionArgElement can potentially use negative indices to mean interesting, but
non option, states
Modified:
lldb/trunk/source/Interpreter/Options.cpp
Modified: lldb/trunk/source/Interpreter/Options.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Interpreter/Options.cpp?rev=274159&r1=274158&r2=274159&view=diff
==
--- lldb/trunk/source/Interpreter/Options.cpp (original)
+++ lldb/trunk/source/Interpreter/Options.cpp Wed Jun 29 15:23:03 2016
@@ -964,6 +964,13 @@ Options::HandleOptionArgumentCompletion
for (size_t i = 0; i < opt_element_vector.size(); i++)
{
int cur_defs_index = opt_element_vector[i].opt_defs_index;
+
+// trying to use <0 indices will definitely cause problems
+if (cur_defs_index == OptionArgElement::eUnrecognizedArg ||
+cur_defs_index == OptionArgElement::eBareDash ||
+cur_defs_index == OptionArgElement::eBareDoubleDash)
+continue;
+
int cur_arg_pos= opt_element_vector[i].opt_arg_pos;
const char *cur_opt_name = opt_defs[cur_defs_index].long_option;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D20464: [LLDB][MIPS] Check if libatomic needs to be specified explicitly.
Eugene.Zelenko added a subscriber: Eugene.Zelenko. Eugene.Zelenko added a comment. This change broke standalone build. Looks like check which should set HAVE_CXX_ATOMICS64_WITHOUT_LIB was not performed. I build LLDB with LLVM STL which doesn't have libatomic. Repository: rL LLVM http://reviews.llvm.org/D20464 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r274164 - Add NSTaggedPointerString to the table of data formatters
Author: enrico
Date: Wed Jun 29 16:00:18 2016
New Revision: 274164
URL: http://llvm.org/viewvc/llvm-project?rev=274164&view=rev
Log:
Add NSTaggedPointerString to the table of data formatters
Fixes rdar://27002512
Modified:
lldb/trunk/source/Plugins/Language/ObjC/ObjCLanguage.cpp
Modified: lldb/trunk/source/Plugins/Language/ObjC/ObjCLanguage.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Language/ObjC/ObjCLanguage.cpp?rev=274164&r1=274163&r2=274164&view=diff
==
--- lldb/trunk/source/Plugins/Language/ObjC/ObjCLanguage.cpp (original)
+++ lldb/trunk/source/Plugins/Language/ObjC/ObjCLanguage.cpp Wed Jun 29
16:00:18 2016
@@ -538,6 +538,7 @@ LoadObjCFormatters(TypeCategoryImplSP ob
AddCXXSummary(objc_category_sp,
lldb_private::formatters::NSStringSummaryProvider, "NSString summary provider",
ConstString("NSCFConstantString"), appkit_flags);
AddCXXSummary(objc_category_sp,
lldb_private::formatters::NSStringSummaryProvider, "NSString summary provider",
ConstString("NSCFString"), appkit_flags);
AddCXXSummary(objc_category_sp,
lldb_private::formatters::NSStringSummaryProvider, "NSString summary provider",
ConstString("NSPathStore2"), appkit_flags);
+AddCXXSummary(objc_category_sp,
lldb_private::formatters::NSStringSummaryProvider, "NSString summary provider",
ConstString("NSTaggedPointerString"), appkit_flags);
AddCXXSummary(objc_category_sp,
lldb_private::formatters::NSAttributedStringSummaryProvider,
"NSAttributedString summary provider", ConstString("NSAttributedString"),
appkit_flags);
AddCXXSummary(objc_category_sp,
lldb_private::formatters::NSMutableAttributedStringSummaryProvider,
"NSMutableAttributedString summary provider",
ConstString("NSMutableAttributedString"), appkit_flags);
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
