[Lldb-commits] Buildbot numbers for the last week of 6/05/2016 - 6/11/2016

[Galina Kistanova via lldb-commits]

Hello everyone,

Below are some buildbot numbers for the last week of 6/05/2016 - 6/11/2016.

Thanks

Galina



 buildername   |  was_red
---+---
 sanitizer-x86_64-linux-bootstrap  | 134:12:25
 perf-x86_64-penryn-O3-polly-parallel-fast | 46:29:26
 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast| 37:56:11
 polly-amd64-linux | 34:53:03
 sanitizer-x86_64-linux-fuzzer | 30:17:25
 clang-x64-ninja-win7  | 25:37:00
 llvm-clang-lld-x86_64-debian-fast | 25:32:54
 clang-cmake-thumbv7-a15-full-sh   | 25:31:44
 clang-x86-win2008-selfhost| 25:25:42
 clang-atom-d525-fedora-rel| 24:52:25
 sanitizer-x86_64-linux| 24:21:15
 clang-ppc64be-linux-lnt   | 24:19:40
 clang-ppc64be-linux   | 24:02:53
 sanitizer-ppc64le-linux   | 22:44:45
 lldb-windows7-android | 20:42:45
 sanitizer-ppc64be-linux   | 19:49:26
 llvm-sphinx-docs  | 19:44:43
 clang-s390x-linux | 17:18:07
 clang-cmake-mips  | 16:39:48
 perf-x86_64-penryn-O3 | 16:32:12
 clang-cuda-build  | 12:52:45
 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast  | 11:58:08
 perf-x86_64-penryn-O3-polly-before-vectorizer-detect-only | 11:23:05
 clang-ppc64le-linux   | 10:55:20
 perf-x86_64-penryn-O3-polly   | 10:09:52
 libcxx-libcxxabi-x86_64-linux-debian  | 06:31:45
 clang-cmake-armv7-a15-selfhost| 04:54:20
 clang-ppc64le-linux-multistage| 04:39:08
 clang-cmake-mipsel| 04:07:57
 lldb-x86_64-darwin-13.4   | 04:07:15
 clang-native-arm-lnt  | 04:02:19
 lld-x86_64-win7   | 04:01:13
 clang-cmake-aarch64-full  | 03:44:15
 clang-cmake-armv7-a15-full| 03:39:18
 clang-cmake-armv7-a15 | 03:28:48
 clang-cmake-thumbv7-a15   | 03:28:06
 libcxx-libcxxabi-arm-linux| 03:19:42
 clang-ppc64le-linux-lnt   | 03:17:11
 clang-x86_64-linux-selfhost-modules   | 02:58:31
 clang-cmake-aarch64-quick | 02:39:58
 libcxx-libcxxabi-x86_64-linux-ubuntu-unstable-abi | 02:25:49
 libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11  | 02:25:33
 libcxx-libcxxabi-x86_64-linux-ubuntu-msan | 02:22:56
 llvm-mips-linux   | 02:22:54
 libcxx-libcxxabi-x86_64-linux-ubuntu-tsan | 02:22:39
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03| 02:19:56
 libcxx-libcxxabi-x86_64-linux-ubuntu-asan | 02:19:30
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx1z| 02:17:10
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14| 02:14:04
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx11| 02:13:58
 libcxx-libcxxabi-libunwind-x86_64-linux-ubuntu| 02:13:27
 lldb-x86_64-ubuntu-14.04-android  | 02:10:25
 lldb-x86_64-ubuntu-14.04-buildserver  | 02:02:39
 clang-x86_64-debian-fast  | 01:52:47
 sanitizer-x86_64-linux-fast   | 01:41:33
 lldb-amd64-ninja-netbsd7  | 01:36:27
 perf-x86_64-penryn-O3-polly-unprofitable  | 01:33:54
 clang-x86_64-linux-abi-test   | 01:26:12
 sanitizer-x86_64-linux-autoconf   | 01:21:50
 llvm-hexagon-elf  | 00:57:39
 clang-hexagon-elf | 00:54:37
 lldb-amd64-ninja-freebsd11| 00:43:02
 lldb-x86_64-ubuntu-14.04-cmake| 00:35:59
 lld-x86_64-freebsd| 00:26:47
 perf-x86_64-penryn-O3-polly-fast  | 00:25:38
 sanitizer-windows | 00:24:51
 lld-x86_64-darwin13   | 00:16:59
(67 rows)


"Status change ratio" by active builder 

[Lldb-commits] LLVM buildmaster will be restarted tonight

[Galina Kistanova via lldb-commits]

Hello everyone,

LLVM buildmaster will be restarted after 8 PM Pacific time today.

Thanks

Galina
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D21296: [lldb] Fixed race condition on private state thread exit, take 2

[Pavel Labath via lldb-commits]

labath added a subscriber: labath.
labath added a comment.

OK, i see. Thanks for the explanation. This may actually be some
windows specific thing then, as I remember zachary mentioning they
have some flakyness issues there.

BTW, this has sped up the LLDB test suite nearly 2x, so thanks a lot
for that. :)

pl


Repository:
  rL LLVM

http://reviews.llvm.org/D21296



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D21296: [lldb] Fixed race condition on private state thread exit, take 2

[Pavel Labath via lldb-commits]

OK, i see. Thanks for the explanation. This may actually be some
windows specific thing then, as I remember zachary mentioning they
have some flakyness issues there.

BTW, this has sped up the LLDB test suite nearly 2x, so thanks a lot
for that. :)

pl


On 14 June 2016 at 17:13, Cameron  wrote:
> cameron314 added a comment.
>
> Thanks everyone :-)
>
> Ah, yeah, sorry if I gave the wrong impression, but that comment is not 
> specific to Linux (in fact, I've only seen it once, on Windows). At one point 
> the debugger had entered ControlPrivateStateThread on one thread to stop it, 
> seen that the thread was already in an invalid state (it was), and assumed 
> that meant that the thread was already exiting and did a join without sending 
> the stop. But the state thread somehow wasn't on its way out yet, it was 
> stuck waiting for a control event first (this is the part that I'm not sure 
> should be possible, but empirically is). This caused a deadlock. So I changed 
> my patch to always send the event if the thread is joinable, not just if its 
> state is valid, and left that comment to explain why this must remain so.
>
>
> http://reviews.llvm.org/D21296
>
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D21324: Remove Platform usages from NativeProcessLinux

[Pavel Labath via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL272686: Remove Platform usages from NativeProcessLinux 
(authored by labath).

Changed prior to commit:
  http://reviews.llvm.org/D21324?vs=60679=60705#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D21324

Files:
  lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp
  lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.h

Index: lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.h
===
--- lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.h
+++ lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.h
@@ -26,7 +26,6 @@
 
 namespace lldb_private {
 class Error;
-class Module;
 class Scalar;
 
 namespace process_linux {
@@ -156,18 +155,12 @@
 /// launching a child process.
 struct LaunchArgs
 {
-LaunchArgs(Module *module,
-char const **argv,
-char const **envp,
-const FileSpec _file_spec,
-const FileSpec _file_spec,
-const FileSpec _file_spec,
-const FileSpec _dir,
-const ProcessLaunchInfo _info);
+LaunchArgs(char const **argv, char const **envp, const FileSpec _file_spec,
+   const FileSpec _file_spec, const FileSpec _file_spec, const FileSpec _dir,
+   const ProcessLaunchInfo _info);
 
 ~LaunchArgs();
 
-Module *m_module;  // The executable image to launch.
 char const **m_argv;   // Process arguments.
 char const **m_envp;   // Process environment.
 const FileSpec m_stdin_file_spec;  // Redirect stdin if not empty.
@@ -189,7 +182,6 @@
 void
 LaunchInferior (
 MainLoop ,
-Module *module,
 char const *argv[],
 char const *envp[],
 const FileSpec _file_spec,
Index: lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp
===
--- lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp
+++ lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp
@@ -25,15 +25,14 @@
 // Other libraries and framework includes
 #include "lldb/Core/EmulateInstruction.h"
 #include "lldb/Core/Error.h"
-#include "lldb/Core/Module.h"
 #include "lldb/Core/ModuleSpec.h"
 #include "lldb/Core/RegisterValue.h"
 #include "lldb/Core/State.h"
-#include "lldb/Host/common/NativeBreakpoint.h"
-#include "lldb/Host/common/NativeRegisterContext.h"
 #include "lldb/Host/Host.h"
 #include "lldb/Host/ThreadLauncher.h"
-#include "lldb/Target/Platform.h"
+#include "lldb/Host/common/NativeBreakpoint.h"
+#include "lldb/Host/common/NativeRegisterContext.h"
+#include "lldb/Symbol/ObjectFile.h"
 #include "lldb/Target/Process.h"
 #include "lldb/Target/ProcessLaunchInfo.h"
 #include "lldb/Target/Target.h"
@@ -110,33 +109,26 @@
 
 namespace
 {
-Error
-ResolveProcessArchitecture (lldb::pid_t pid, Platform , ArchSpec )
-{
-// Grab process info for the running process.
-ProcessInstanceInfo process_info;
-if (!platform.GetProcessInfo (pid, process_info))
-return Error("failed to get process info");
-
-// Resolve the executable module.
-ModuleSP exe_module_sp;
-ModuleSpec exe_module_spec(process_info.GetExecutableFile(), process_info.GetArchitecture());
-FileSpecList executable_search_paths (Target::GetDefaultExecutableSearchPaths ());
-Error error = platform.ResolveExecutable(
-exe_module_spec,
-exe_module_sp,
-executable_search_paths.GetSize () ? _search_paths : NULL);
+Error
+ResolveProcessArchitecture(lldb::pid_t pid, ArchSpec )
+{
+// Grab process info for the running process.
+ProcessInstanceInfo process_info;
+if (!Host::GetProcessInfo(pid, process_info))
+return Error("failed to get process info");
 
-if (!error.Success ())
-return error;
+// Resolve the executable module.
+ModuleSpecList module_specs;
+if (!ObjectFile::GetModuleSpecifications(process_info.GetExecutableFile(), 0, 0, module_specs))
+return Error("failed to get module specifications");
+assert(module_specs.GetSize() == 1);
 
-// Check if we've got our architecture from the exe_module.
-arch = exe_module_sp->GetArchitecture ();
-if (arch.IsValid ())
-return Error();
-else
-return Error("failed to retrieve a valid architecture from the exe module");
-}
+arch = module_specs.GetModuleSpecRefAtIndex(0).GetArchitecture();
+if (arch.IsValid())
+return Error();
+else
+return Error("failed to retrieve a valid architecture from the exe module");

[Lldb-commits] [lldb] r272686 - Remove Platform usages from NativeProcessLinux

[Pavel Labath via lldb-commits]

Author: labath
Date: Tue Jun 14 12:30:52 2016
New Revision: 272686

URL: http://llvm.org/viewvc/llvm-project?rev=272686=rev
Log:
Remove Platform usages from NativeProcessLinux

Summary:
This removes the last usage of the Platform plugin in NPL. It was being
used for determining the architecture of the debugged process. I replace
the call that went through the Platform plugin with a lower level call
on the ObjectFile directly.

Reviewers: tberghammer

Subscribers: uweigand, nitesh.jain, omjavaid, lldb-commits

Differential Revision: http://reviews.llvm.org/D21324

Modified:
lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp
lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.h

Modified: lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp?rev=272686=272685=272686=diff
==
--- lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp (original)
+++ lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp Tue Jun 14 
12:30:52 2016
@@ -25,15 +25,14 @@
 // Other libraries and framework includes
 #include "lldb/Core/EmulateInstruction.h"
 #include "lldb/Core/Error.h"
-#include "lldb/Core/Module.h"
 #include "lldb/Core/ModuleSpec.h"
 #include "lldb/Core/RegisterValue.h"
 #include "lldb/Core/State.h"
-#include "lldb/Host/common/NativeBreakpoint.h"
-#include "lldb/Host/common/NativeRegisterContext.h"
 #include "lldb/Host/Host.h"
 #include "lldb/Host/ThreadLauncher.h"
-#include "lldb/Target/Platform.h"
+#include "lldb/Host/common/NativeBreakpoint.h"
+#include "lldb/Host/common/NativeRegisterContext.h"
+#include "lldb/Symbol/ObjectFile.h"
 #include "lldb/Target/Process.h"
 #include "lldb/Target/ProcessLaunchInfo.h"
 #include "lldb/Target/Target.h"
@@ -110,33 +109,26 @@ static bool ProcessVmReadvSupported()
 
 namespace
 {
-Error
-ResolveProcessArchitecture (lldb::pid_t pid, Platform , ArchSpec 
)
-{
-// Grab process info for the running process.
-ProcessInstanceInfo process_info;
-if (!platform.GetProcessInfo (pid, process_info))
-return Error("failed to get process info");
-
-// Resolve the executable module.
-ModuleSP exe_module_sp;
-ModuleSpec exe_module_spec(process_info.GetExecutableFile(), 
process_info.GetArchitecture());
-FileSpecList executable_search_paths 
(Target::GetDefaultExecutableSearchPaths ());
-Error error = platform.ResolveExecutable(
-exe_module_spec,
-exe_module_sp,
-executable_search_paths.GetSize () ? _search_paths : 
NULL);
-
-if (!error.Success ())
-return error;
+Error
+ResolveProcessArchitecture(lldb::pid_t pid, ArchSpec )
+{
+// Grab process info for the running process.
+ProcessInstanceInfo process_info;
+if (!Host::GetProcessInfo(pid, process_info))
+return Error("failed to get process info");
 
-// Check if we've got our architecture from the exe_module.
-arch = exe_module_sp->GetArchitecture ();
-if (arch.IsValid ())
-return Error();
-else
-return Error("failed to retrieve a valid architecture from the exe 
module");
-}
+// Resolve the executable module.
+ModuleSpecList module_specs;
+if (!ObjectFile::GetModuleSpecifications(process_info.GetExecutableFile(), 
0, 0, module_specs))
+return Error("failed to get module specifications");
+assert(module_specs.GetSize() == 1);
+
+arch = module_specs.GetModuleSpecRefAtIndex(0).GetArchitecture();
+if (arch.IsValid())
+return Error();
+else
+return Error("failed to retrieve a valid architecture from the exe 
module");
+}
 
 void
 DisplayBytes (StreamString , void *bytes, uint32_t count)
@@ -238,16 +230,10 @@ EnsureFDFlags(int fd, int flags)
 return error;
 }
 
-NativeProcessLinux::LaunchArgs::LaunchArgs(Module *module,
-   char const **argv,
-   char const **envp,
-   const FileSpec _file_spec,
-   const FileSpec _file_spec,
-   const FileSpec _file_spec,
-   const FileSpec _dir,
-   const ProcessLaunchInfo _info)
-: m_module(module),
-  m_argv(argv),
+NativeProcessLinux::LaunchArgs::LaunchArgs(char const **argv, char const 
**envp, const FileSpec _file_spec,
+   const FileSpec _file_spec, 
const FileSpec _file_spec,
+   const FileSpec _dir, const 
ProcessLaunchInfo _info)
+: m_argv(argv),
   m_envp(envp),
   m_stdin_file_spec(stdin_file_spec),
   m_stdout_file_spec(stdout_file_spec),
@@ 

[Lldb-commits] [PATCH] D21328: [lldb] Fixed incorrect endianness when evaluating certain expressions

[Cameron via lldb-commits]

cameron314 created this revision.
cameron314 added reviewers: spyffe, zturner, clayborg.
cameron314 added a subscriber: lldb-commits.

The `EntityVariable` materializer was, under certain conditions, taking the 
bytes of a `DataExtractor` that were potentially in host order (e.g. little 
endian) and putting them in the `IRMemoryMap` (which assumes all values are in 
target order, e.g. big endian). This caused certain values to have the wrong 
endianness during expression evaluation.

On our platform, this manifested as certain expressions yielding incorrect 
results when the variables were in registers (e.g. `argc + 1` would give 
`0x0101`).

http://reviews.llvm.org/D21328

Files:
  include/lldb/Expression/IRMemoryMap.h
  source/Expression/IRMemoryMap.cpp
  source/Expression/Materializer.cpp

Index: source/Expression/Materializer.cpp
===
--- source/Expression/Materializer.cpp
+++ source/Expression/Materializer.cpp
@@ -575,7 +575,7 @@
 
 Error write_error;
 
-map.WriteMemory(m_temporary_allocation, data.GetDataStart(), 
data.GetByteSize(), write_error);
+map.WriteMemory(m_temporary_allocation, data.GetDataStart(), 
data.GetByteSize(), data.GetByteOrder(), write_error);
 
 if (!write_error.Success())
 {
Index: source/Expression/IRMemoryMap.cpp
===
--- source/Expression/IRMemoryMap.cpp
+++ source/Expression/IRMemoryMap.cpp
@@ -564,6 +564,22 @@
 }
 
 void
+IRMemoryMap::WriteMemory(lldb::addr_t process_address, const uint8_t *bytes, 
size_t size, lldb::ByteOrder byteOrder, Error )
+{
+std::vector temp;
+if (byteOrder != GetByteOrder())
+{
+// Need to byte-swap the bytes before putting them in the map, 
otherwise they'll
+// be interpreted with the wrong endianness when they're read back out.
+temp.reserve(size);
+typedef std::reverse_iterator revit;
+temp.assign(revit(bytes + size), revit(bytes));
+bytes = temp.data();
+}
+WriteMemory(process_address, bytes, size, error);
+}
+
+void
 IRMemoryMap::WriteMemory (lldb::addr_t process_address, const uint8_t *bytes, 
size_t size, Error )
 {
 error.Clear();
Index: include/lldb/Expression/IRMemoryMap.h
===
--- include/lldb/Expression/IRMemoryMap.h
+++ include/lldb/Expression/IRMemoryMap.h
@@ -60,6 +60,7 @@
 void Free (lldb::addr_t process_address, Error );
 
 void WriteMemory (lldb::addr_t process_address, const uint8_t *bytes, 
size_t size, Error );
+void WriteMemory (lldb::addr_t process_address, const uint8_t *bytes, 
size_t size, lldb::ByteOrder order, Error );
 void WriteScalarToMemory (lldb::addr_t process_address, Scalar , 
size_t size, Error );
 void WritePointerToMemory (lldb::addr_t process_address, lldb::addr_t 
address, Error );
 void ReadMemory (uint8_t *bytes, lldb::addr_t process_address, size_t 
size, Error );


Index: source/Expression/Materializer.cpp
===
--- source/Expression/Materializer.cpp
+++ source/Expression/Materializer.cpp
@@ -575,7 +575,7 @@
 
 Error write_error;
 
-map.WriteMemory(m_temporary_allocation, data.GetDataStart(), data.GetByteSize(), write_error);
+map.WriteMemory(m_temporary_allocation, data.GetDataStart(), data.GetByteSize(), data.GetByteOrder(), write_error);
 
 if (!write_error.Success())
 {
Index: source/Expression/IRMemoryMap.cpp
===
--- source/Expression/IRMemoryMap.cpp
+++ source/Expression/IRMemoryMap.cpp
@@ -564,6 +564,22 @@
 }
 
 void
+IRMemoryMap::WriteMemory(lldb::addr_t process_address, const uint8_t *bytes, size_t size, lldb::ByteOrder byteOrder, Error )
+{
+std::vector temp;
+if (byteOrder != GetByteOrder())
+{
+// Need to byte-swap the bytes before putting them in the map, otherwise they'll
+// be interpreted with the wrong endianness when they're read back out.
+temp.reserve(size);
+typedef std::reverse_iterator revit;
+temp.assign(revit(bytes + size), revit(bytes));
+bytes = temp.data();
+}
+WriteMemory(process_address, bytes, size, error);
+}
+
+void
 IRMemoryMap::WriteMemory (lldb::addr_t process_address, const uint8_t *bytes, size_t size, Error )
 {
 error.Clear();
Index: include/lldb/Expression/IRMemoryMap.h
===
--- include/lldb/Expression/IRMemoryMap.h
+++ include/lldb/Expression/IRMemoryMap.h
@@ -60,6 +60,7 @@
 void Free (lldb::addr_t process_address, Error );
 
 void WriteMemory (lldb::addr_t process_address, const uint8_t *bytes, size_t size, Error );
+void WriteMemory 

Re: [Lldb-commits] [PATCH] D21296: [lldb] Fixed race condition on private state thread exit, take 2

[Cameron via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL272682: [lldb] Fixed race conditions on private state thread 
exit (authored by cameron314).

Changed prior to commit:
  http://reviews.llvm.org/D21296?vs=60536=60693#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D21296

Files:
  lldb/trunk/include/lldb/Target/Process.h
  lldb/trunk/source/Target/Process.cpp

Index: lldb/trunk/source/Target/Process.cpp
===
--- lldb/trunk/source/Target/Process.cpp
+++ lldb/trunk/source/Target/Process.cpp
@@ -4088,7 +4088,7 @@
 void
 Process::StopPrivateStateThread ()
 {
-if (PrivateStateThreadIsValid ())
+if (m_private_state_thread.IsJoinable ())
 ControlPrivateStateThread (eBroadcastInternalStateControlStop);
 else
 {
@@ -4110,21 +4110,23 @@
 if (log)
 log->Printf ("Process::%s (signal = %d)", __FUNCTION__, signal);
 
-// Signal the private state thread. First we should copy this is case the
-// thread starts exiting since the private state thread will NULL this out
-// when it exits
+// Signal the private state thread
+if (m_private_state_thread.IsJoinable())
 {
-HostThread private_state_thread(m_private_state_thread);
-if (private_state_thread.IsJoinable())
+// Broadcast the event.
+// It is important to do this outside of the if below, because
+// it's possible that the thread state is invalid but that the
+// thread is waiting on a control event instead of simply being
+// on its way out (this should not happen, but it apparently can).
+if (log)
+log->Printf ("Sending control event of type: %d.", signal);
+std::shared_ptr event_receipt_sp(new EventDataReceipt());
+m_private_state_control_broadcaster.BroadcastEvent(signal, event_receipt_sp);
+
+// Wait for the event receipt or for the private state thread to exit
+bool receipt_received = false;
+if (PrivateStateThreadIsValid())
 {
-if (log)
-log->Printf ("Sending control event of type: %d.", signal);
-// Send the control event and wait for the receipt or for the private state
-// thread to exit
-std::shared_ptr event_receipt_sp(new EventDataReceipt());
-m_private_state_control_broadcaster.BroadcastEvent(signal, event_receipt_sp);
-
-bool receipt_received = false;
 while (!receipt_received)
 {
 bool timed_out = false;
@@ -4137,23 +4139,24 @@
 if (!receipt_received)
 {
 // Check if the private state thread is still around. If it isn't then we are done waiting
-if (!m_private_state_thread.IsJoinable())
-break; // Private state thread exited, we are done
+if (!PrivateStateThreadIsValid())
+break; // Private state thread exited or is exiting, we are done
 }
 }
-
-if (signal == eBroadcastInternalStateControlStop)
-{
-thread_result_t result = NULL;
-private_state_thread.Join();
-}
 }
-else
+
+if (signal == eBroadcastInternalStateControlStop)
 {
-if (log)
-log->Printf ("Private state thread already dead, no need to signal it to stop.");
+thread_result_t result = NULL;
+m_private_state_thread.Join();
+m_private_state_thread.Reset();
 }
 }
+else
+{
+if (log)
+log->Printf("Private state thread already dead, no need to signal it to stop.");
+}
 }
 
 void
@@ -4446,7 +4449,6 @@
 // try to change it on the way out.
 if (!is_secondary_thread)
 m_public_run_lock.SetStopped();
-m_private_state_thread.Reset();
 return NULL;
 }
 
Index: lldb/trunk/include/lldb/Target/Process.h
===
--- lldb/trunk/include/lldb/Target/Process.h
+++ lldb/trunk/include/lldb/Target/Process.h
@@ -3309,9 +3309,13 @@
 bool
 PrivateStateThreadIsValid () const
 {
-return m_private_state_thread.IsJoinable();
+lldb::StateType state = m_private_state.GetValue();
+return state != lldb::eStateInvalid &&
+   state != lldb::eStateDetached &&
+   state != lldb::eStateExited &&
+   m_private_state_thread.IsJoinable();
 }
-
+
 void
 ForceNextEventDelivery()
 {
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r272682 - [lldb] Fixed race conditions on private state thread exit

[Cameron Desrochers via lldb-commits]

Author: cameron314
Date: Tue Jun 14 11:22:45 2016
New Revision: 272682

URL: http://llvm.org/viewvc/llvm-project?rev=272682=rev
Log:
[lldb] Fixed race conditions on private state thread exit

This patch fixes various races between the time the private state thread is 
signaled to exit and the time it actually exits (during which it no longer 
responds to events). Previously, this was consistently causing 2-second timeout 
delays on process detach/stop for us.

This also prevents crashes that were caused by the thread controlling its own 
owning pointer while the controller was using it (copying the thread wrapper is 
not enough to mitigate this, since the internal thread object was getting reset 
anyway). Again, we were seeing this consistently.

Differential Revision: http://reviews.llvm.org/D21296

Modified:
lldb/trunk/include/lldb/Target/Process.h
lldb/trunk/source/Target/Process.cpp

Modified: lldb/trunk/include/lldb/Target/Process.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Target/Process.h?rev=272682=272681=272682=diff
==
--- lldb/trunk/include/lldb/Target/Process.h (original)
+++ lldb/trunk/include/lldb/Target/Process.h Tue Jun 14 11:22:45 2016
@@ -3309,9 +3309,13 @@ protected:
 bool
 PrivateStateThreadIsValid () const
 {
-return m_private_state_thread.IsJoinable();
+lldb::StateType state = m_private_state.GetValue();
+return state != lldb::eStateInvalid &&
+   state != lldb::eStateDetached &&
+   state != lldb::eStateExited &&
+   m_private_state_thread.IsJoinable();
 }
-
+
 void
 ForceNextEventDelivery()
 {

Modified: lldb/trunk/source/Target/Process.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/Process.cpp?rev=272682=272681=272682=diff
==
--- lldb/trunk/source/Target/Process.cpp (original)
+++ lldb/trunk/source/Target/Process.cpp Tue Jun 14 11:22:45 2016
@@ -4088,7 +4088,7 @@ Process::ResumePrivateStateThread ()
 void
 Process::StopPrivateStateThread ()
 {
-if (PrivateStateThreadIsValid ())
+if (m_private_state_thread.IsJoinable ())
 ControlPrivateStateThread (eBroadcastInternalStateControlStop);
 else
 {
@@ -4110,21 +4110,23 @@ Process::ControlPrivateStateThread (uint
 if (log)
 log->Printf ("Process::%s (signal = %d)", __FUNCTION__, signal);
 
-// Signal the private state thread. First we should copy this is case the
-// thread starts exiting since the private state thread will NULL this out
-// when it exits
+// Signal the private state thread
+if (m_private_state_thread.IsJoinable())
 {
-HostThread private_state_thread(m_private_state_thread);
-if (private_state_thread.IsJoinable())
+// Broadcast the event.
+// It is important to do this outside of the if below, because
+// it's possible that the thread state is invalid but that the
+// thread is waiting on a control event instead of simply being
+// on its way out (this should not happen, but it apparently can).
+if (log)
+log->Printf ("Sending control event of type: %d.", signal);
+std::shared_ptr event_receipt_sp(new 
EventDataReceipt());
+m_private_state_control_broadcaster.BroadcastEvent(signal, 
event_receipt_sp);
+
+// Wait for the event receipt or for the private state thread to exit
+bool receipt_received = false;
+if (PrivateStateThreadIsValid())
 {
-if (log)
-log->Printf ("Sending control event of type: %d.", signal);
-// Send the control event and wait for the receipt or for the 
private state
-// thread to exit
-std::shared_ptr event_receipt_sp(new 
EventDataReceipt());
-m_private_state_control_broadcaster.BroadcastEvent(signal, 
event_receipt_sp);
-
-bool receipt_received = false;
 while (!receipt_received)
 {
 bool timed_out = false;
@@ -4137,23 +4139,24 @@ Process::ControlPrivateStateThread (uint
 if (!receipt_received)
 {
 // Check if the private state thread is still around. If 
it isn't then we are done waiting
-if (!m_private_state_thread.IsJoinable())
-break; // Private state thread exited, we are done
+if (!PrivateStateThreadIsValid())
+break; // Private state thread exited or is exiting, 
we are done
 }
 }
-
-if (signal == eBroadcastInternalStateControlStop)
-{
-thread_result_t result = NULL;
-private_state_thread.Join();
-}
 }
-else
+
+if (signal == 

Re: [Lldb-commits] [PATCH] D21324: Remove Platform usages from NativeProcessLinux

[Tamas Berghammer via lldb-commits]

tberghammer accepted this revision.
tberghammer added a comment.
This revision is now accepted and ready to land.

Looks good


http://reviews.llvm.org/D21324



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D20368: Remove Platform usages from NativeProcessLinux

[Pavel Labath via lldb-commits]

labath abandoned this revision.
labath added a comment.

I am abandoning this in favor of http://reviews.llvm.org/D21324, which achieves 
the same result (no Platform plugin), but still uses the elf-parsing method to 
keep everything working as is now.

You can give it a try if you want, but I don't anticipate any 
architecture-specific problems as all the changes are in generic code. Thanks 
for the patience.



Comment at: source/Plugins/Process/Linux/NativeProcessLinux.cpp:2072-2073
@@ -2164,4 +2071,4 @@
 
 lldb::addr_t
 NativeProcessLinux::GetSharedLibraryInfoAddress ()
 {

The function is pure virtual in the base class, so I cannot just remove it.


http://reviews.llvm.org/D20368



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D21324: Remove Platform usages from NativeProcessLinux

[Pavel Labath via lldb-commits]

labath created this revision.
labath added a reviewer: tberghammer.
labath added subscribers: lldb-commits, omjavaid, nitesh.jain, uweigand.

This removes the last usage of the Platform plugin in NPL. It was being
used for determining the architecture of the debugged process. I replace
the call that went through the Platform plugin with a lower level call
on the ObjectFile directly.

http://reviews.llvm.org/D21324

Files:
  source/Plugins/Process/Linux/NativeProcessLinux.cpp
  source/Plugins/Process/Linux/NativeProcessLinux.h

Index: source/Plugins/Process/Linux/NativeProcessLinux.h
===
--- source/Plugins/Process/Linux/NativeProcessLinux.h
+++ source/Plugins/Process/Linux/NativeProcessLinux.h
@@ -26,7 +26,6 @@
 
 namespace lldb_private {
 class Error;
-class Module;
 class Scalar;
 
 namespace process_linux {
@@ -156,18 +155,12 @@
 /// launching a child process.
 struct LaunchArgs
 {
-LaunchArgs(Module *module,
-char const **argv,
-char const **envp,
-const FileSpec _file_spec,
-const FileSpec _file_spec,
-const FileSpec _file_spec,
-const FileSpec _dir,
-const ProcessLaunchInfo _info);
+LaunchArgs(char const **argv, char const **envp, const FileSpec _file_spec,
+   const FileSpec _file_spec, const FileSpec _file_spec, const FileSpec _dir,
+   const ProcessLaunchInfo _info);
 
 ~LaunchArgs();
 
-Module *m_module;  // The executable image to launch.
 char const **m_argv;   // Process arguments.
 char const **m_envp;   // Process environment.
 const FileSpec m_stdin_file_spec;  // Redirect stdin if not empty.
@@ -189,7 +182,6 @@
 void
 LaunchInferior (
 MainLoop ,
-Module *module,
 char const *argv[],
 char const *envp[],
 const FileSpec _file_spec,
Index: source/Plugins/Process/Linux/NativeProcessLinux.cpp
===
--- source/Plugins/Process/Linux/NativeProcessLinux.cpp
+++ source/Plugins/Process/Linux/NativeProcessLinux.cpp
@@ -25,15 +25,14 @@
 // Other libraries and framework includes
 #include "lldb/Core/EmulateInstruction.h"
 #include "lldb/Core/Error.h"
-#include "lldb/Core/Module.h"
 #include "lldb/Core/ModuleSpec.h"
 #include "lldb/Core/RegisterValue.h"
 #include "lldb/Core/State.h"
-#include "lldb/Host/common/NativeBreakpoint.h"
-#include "lldb/Host/common/NativeRegisterContext.h"
 #include "lldb/Host/Host.h"
 #include "lldb/Host/ThreadLauncher.h"
-#include "lldb/Target/Platform.h"
+#include "lldb/Host/common/NativeBreakpoint.h"
+#include "lldb/Host/common/NativeRegisterContext.h"
+#include "lldb/Symbol/ObjectFile.h"
 #include "lldb/Target/Process.h"
 #include "lldb/Target/ProcessLaunchInfo.h"
 #include "lldb/Target/Target.h"
@@ -110,33 +109,26 @@
 
 namespace
 {
-Error
-ResolveProcessArchitecture (lldb::pid_t pid, Platform , ArchSpec )
-{
-// Grab process info for the running process.
-ProcessInstanceInfo process_info;
-if (!platform.GetProcessInfo (pid, process_info))
-return Error("failed to get process info");
-
-// Resolve the executable module.
-ModuleSP exe_module_sp;
-ModuleSpec exe_module_spec(process_info.GetExecutableFile(), process_info.GetArchitecture());
-FileSpecList executable_search_paths (Target::GetDefaultExecutableSearchPaths ());
-Error error = platform.ResolveExecutable(
-exe_module_spec,
-exe_module_sp,
-executable_search_paths.GetSize () ? _search_paths : NULL);
+Error
+ResolveProcessArchitecture(lldb::pid_t pid, ArchSpec )
+{
+// Grab process info for the running process.
+ProcessInstanceInfo process_info;
+if (!Host::GetProcessInfo(pid, process_info))
+return Error("failed to get process info");
 
-if (!error.Success ())
-return error;
+// Resolve the executable module.
+ModuleSpecList module_specs;
+if (!ObjectFile::GetModuleSpecifications(process_info.GetExecutableFile(), 0, 0, module_specs))
+return Error("failed to get module specifications");
+assert(module_specs.GetSize() == 1);
 
-// Check if we've got our architecture from the exe_module.
-arch = exe_module_sp->GetArchitecture ();
-if (arch.IsValid ())
-return Error();
-else
-return Error("failed to retrieve a valid architecture from the exe module");
-}
+arch = module_specs.GetModuleSpecRefAtIndex(0).GetArchitecture();
+if (arch.IsValid())
+return Error();
+else
+return Error("failed to retrieve a valid 

Re: [Lldb-commits] [PATCH] D20565: Add MemoryRegionInfo to SB API

[Howard Hellyer via lldb-commits]

hhellyer added a comment.

Should I be able to deliver these changes now?  When I try following the 
instructions here: http://llvm.org/docs/Phabricator.html the patch 
downloads and applies correctly but whether I use arc via the git or svn 
commit methods I'm ultimately prompted for a password for subversion. I'm 
not sure if I should have a password or if that means the patch doesn't 
match what's expected in some way. I don't know how clever phabricator's 
svn commit hooks are and whether they check against the patch before 
prompting for authentication.

(Or is there a "Land this" button on phabricator I'm missing?)

From:   Greg Clayton 
To: Howard Hellyer/UK/IBM@IBMGB, clayb...@gmail.com
Date:   13/06/2016 21:28
Subject:Re: [PATCH] http://reviews.llvm.org/D20565: Add 
MemoryRegionInfo to SB API

clayborg accepted this revision.
This revision is now accepted and ready to land.

http://reviews.llvm.org/D20565

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number

741598.

Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


http://reviews.llvm.org/D20565



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D21221: Fix for PrintStackTraces

[Pavel Labath via lldb-commits]

labath added a comment.

In http://reviews.llvm.org/D21221#457329, @ravitheja wrote:

> @labath In order to reproduce this situation without the help of standard 
> library, I would have to write handwritten assembly and the CFI directives 
> for that, is that fine ?


Yes, I think that's fine. Obviously that will make the test x86-specific (and 
probably linux-specific, although it would be great if that can be avoided 
(*)), but at least it will be well focused, and not relying on random timings 
in other tests. A less preferred but-still-better-than-status-quo option would 
be to keep the standard library dependency but remove the timing issues (e.g., 
by setting the breakpoint in fflush, instruction-stepping 100 times, and making 
sure you unwind correctly from each place).

(*) One way to do that is to avoid running code. If you can write the test in a 
way that it does not need a running process then you can just check in a tiny 
(linux) module, load it and query some properties of the contained functions 
and their unwind plans...


http://reviews.llvm.org/D21221



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D21221: Fix for PrintStackTraces

[Ravitheja Addepally via lldb-commits]

ravitheja added a comment.

@labath In order to reproduce this situation without the help of standard 
library, I would have to write handwritten assembly and the CFI directives for 
that, is that fine ?


http://reviews.llvm.org/D21221



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D21221: Fix for PrintStackTraces

[Ravitheja Addepally via lldb-commits]

ravitheja added a comment.

so regarding this particular situation I want to give little more insight ->
It starts out from here

  0x40143a <+346>: movabsq $0x403e32, %rdi   ; imm = 0x403E32 
  0x401444 <+356>: movb   $0x0, %al
  0x401446 <+358>: callq  0x400d30  ; symbol stub for: printf
  0x40144b <+363>: movq   0x6071c0, %rdi
  0x401453 <+371>: movl   %eax, -0xdc(%rbp)

->0x401459 <+377>: callq  0x400ed0  ; symbol stub for: fflush

  0x40145e <+382>: movl   $0x40, %esi
  0x401463 <+387>: leaq   -0xb0(%rbp), %rdi
  0x40146a <+394>: movq   0x607158, %rdx
  0x401472 <+402>: movl   %eax, -0xe0(%rbp)

(lldb) disassemble
a.out`fflush:
->  0x400ed0 <+0>:  jmpq   *0x206212(%rip)   ; _GLOBAL_OFFSET_TABLE_ + 
232

  0x400ed6 <+6>:  pushq  $0x1a
  0x400edb <+11>: jmp0x400d20

(lldb) disassemble 
->  0x400d20:   pushq  0x2062e2(%rip); _GLOBAL_OFFSET_TABLE_ + 8

  0x400d26:   jmpq   *0x2062e4(%rip)   ; _GLOBAL_OFFSET_TABLE_ + 16 
  I think this jump goes to fflush.

ld-linux-x86-64.so.2`___lldb_unnamed_symbol95$$ld-linux-x86-64.so.2:

  0x77df04a0 <+0>:  subq   $0x38, %rsp-> The testcase tries to unwind 
out of here and fails.
  0x77df04a4 <+4>:  movq   %rax, (%rsp)
  0x77df04a8 <+8>:  movq   %rcx, 0x8(%rsp)
  0x77df04ad <+13>: movq   %rdx, 0x10(%rsp)
  0x77df04b2 <+18>: movq   %rsi, 0x18(%rsp)
  0x77df04b7 <+23>: movq   %rdi, 0x20(%rsp)
  0x77df04bc <+28>: movq   %r8, 0x28(%rsp)
  0x77df04c1 <+33>: movq   %r9, 0x30(%rsp)
  0x77df04c6 <+38>: movq   0x40(%rsp), %rsi

Now as you can see, from inside fflush its not possible for the assembly unwind 
to figure out the situation. 
@jasonmolenda The functions I posted in the lldb-dev are the same, here i am 
just posting how it got there.
There is eh_frame information for these functions, that is able to correctly 
point out the CFA.

lldb) image show-unwind --address 0x77df04a0
UNWIND PLANS for 
ld-linux-x86-64.so.2`___lldb_unnamed_symbol95$$ld-linux-x86-64.so.2 (start addr 
0x77df04a0)

Asynchronous (not restricted to call-sites) UnwindPlan is 'assembly insn 
profiling'
Synchronous (restricted to call-sites) UnwindPlan is 'eh_frame CFI'

Assembly language inspection UnwindPlan:
This UnwindPlan originally sourced from assembly insn profiling
This UnwindPlan is sourced from the compiler: no.
This UnwindPlan is valid at all instruction locations: yes.
Address range of this UnwindPlan: [ld-linux-x86-64.so.2..text + 
88512-0x00015a30)
row[0]:0: CFA=rsp +8 => rsp=CFA+0 rip=[CFA-8] 
row[1]:4: CFA=rsp+64 => rsp=CFA+0 rip=[CFA-8] 
row[2]:   94: CFA=rsp -8 => rsp=CFA+0 rip=[CFA-8]

eh_frame UnwindPlan:
This UnwindPlan originally sourced from eh_frame CFI
This UnwindPlan is sourced from the compiler: yes.
This UnwindPlan is valid at all instruction locations: no.
Address range of this UnwindPlan: [ld-linux-x86-64.so.2..text + 
88512-0x00015a21)
row[0]:0: CFA=rsp+24 => rip=[CFA-8] 
row[1]:4: CFA=rsp+80 => rip=[CFA-8] 
row[2]:   94: CFA=rsp +8 => rip=[CFA-8]

Arch default UnwindPlan:
This UnwindPlan originally sourced from x86_64 default unwind plan
This UnwindPlan is sourced from the compiler: no.
This UnwindPlan is valid at all instruction locations: no.
row[0]:0: CFA=rbp+16 => rbp=[CFA-16] rsp=CFA+0 rip=[CFA-8]

Arch default at entry point UnwindPlan:
This UnwindPlan originally sourced from x86_64 at-func-entry default
This UnwindPlan is sourced from the compiler: no.
This UnwindPlan is valid at all instruction locations: not specified.
row[0]:0: CFA=rsp +8 => rsp=CFA+0 rip=[CFA-8]

As you can see the eh_frame UnwindPlan is correct here.


http://reviews.llvm.org/D21221



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D21221: Fix for PrintStackTraces

[Ravitheja Addepally via lldb-commits]

ravitheja added inline comments.


Comment at: source/Plugins/Process/Utility/RegisterContextLLDB.cpp:1602
@@ -1610,3 +1601,3 @@
 // isn't going to do any better.
-if (m_full_unwind_plan_sp->GetSourcedFromCompiler() == eLazyBoolYes)
-return false;
+//if (m_full_unwind_plan_sp->GetSourcedFromCompiler() == eLazyBoolYes)
+//return false;

labath wrote:
> What is this supposed to do?
It stops the the TryFallbackUnwindplan to use the assembly unwinder.


http://reviews.llvm.org/D21221



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D21296: [lldb] Fixed race condition on private state thread exit, take 2

[Pavel Labath via lldb-commits]

labath accepted this revision.
labath added a comment.

Seems to run fine on linux now. Thanks for investigating this. We'll monitor 
the buildbots and let you know if anything bad happens. ;)

BTW. your comment in ControlPrivateStateThread seems to indicate that the linux 
behavior is inconsistent/unexpected in some way. Do you think it would be worth 
filing a bug about that?


http://reviews.llvm.org/D21296



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D21280: Allow installing watchpoints at less than 8-byte alligned addresses for AArch64 targets

[Muhammad Omair Javaid via lldb-commits]

omjavaid added a comment.

In http://reviews.llvm.org/D21280#457196, @labath wrote:

> The overall change looks good, but please also add a test which specifically 
> tests for watchpoints at unaligned addresses. Last time I checked, we all 
> watchpoint tests were passing (at least on android) even without this patch, 
> so it looks like our tests coverage is not sufficient here.


Patch causes no regressions and following tests fail without this patch on 
Nexus 9 and arm-linux hikey board:

No test currently fully tests the functionality supported by this patch. So I 
ll add a new test that tests different watchpoint sizes.

UNEXPECTED SUCCESS: test_watchpoint_command_can_disable_a_watchpoint_dwarf 
(functionalities/watchpoint/watchpoint_commands/command/TestWatchpointCommandLLDB.py)
UNEXPECTED SUCCESS: test_watchpoint_command_can_disable_a_watchpoint_dwo 
(functionalities/watchpoint/watchpoint_commands/command/TestWatchpointCommandLLDB.py)
UNEXPECTED SUCCESS: test_watchpoint_command_dwarf 
(functionalities/watchpoint/watchpoint_commands/command/TestWatchpointCommandLLDB.py)
UNEXPECTED SUCCESS: test_watchpoint_command_dwarf 
(functionalities/watchpoint/watchpoint_commands/command/TestWatchpointCommandPython.py)
UNEXPECTED SUCCESS: test_watchpoint_command_dwo 
(functionalities/watchpoint/watchpoint_commands/command/TestWatchpointCommandPython.py)
UNEXPECTED SUCCESS: test_watchpoint_command_dwo 
(functionalities/watchpoint/watchpoint_commands/command/TestWatchpointCommandLLDB.py)
UNEXPECTED SUCCESS: test_watchpoint_cond_api_dwarf 
(python_api/watchpoint/condition/TestWatchpointConditionAPI.py)
UNEXPECTED SUCCESS: test_watchpoint_cond_api_dwo 
(python_api/watchpoint/condition/TestWatchpointConditionAPI.py)
UNEXPECTED SUCCESS: test_watchpoint_cond_dwarf 
(functionalities/watchpoint/watchpoint_commands/condition/TestWatchpointConditionCmd.py)
UNEXPECTED SUCCESS: test_watchpoint_cond_dwo 
(functionalities/watchpoint/watchpoint_commands/condition/TestWatchpointConditionCmd.py)
UNEXPECTED SUCCESS: test_with_python_api_dwarf 
(functionalities/watchpoint/watchpoint_events/TestWatchpointEvents.py)
UNEXPECTED SUCCESS: test_with_python_api_dwo 
(functionalities/watchpoint/watchpoint_events/TestWatchpointEvents.py)

In http://reviews.llvm.org/D21280#456670, @clayborg wrote:

> Does this patch handle being able to share an 8 byte watchpoint between two 
> watchpoints? Lets say you have an 8 byte array named "a" and watch to watch 
> a[0] and a[3] and a[7]. You should be able to allow the watchpoints to share 
> the 1 watchpoint. This patch is fine as is, just something to think about for 
> a future patch.


This functionality may not work with current patch and may require more work. I 
will follow up with another patch after adding support for this kind of 
scenario.


http://reviews.llvm.org/D21280



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits