Re: [Lldb-commits] [PATCH] D21064: [LLDB][MIPS] Fix Emulation of Compact branch and ADDIU instructions

2016-06-08 Thread Jaydeep Patil via lldb-commits
jaydeep accepted this revision.
jaydeep added a comment.
This revision is now accepted and ready to land.

Looks good to me.


Repository:
  rL LLVM

http://reviews.llvm.org/D21064



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


Re: [Lldb-commits] [PATCH] D21159: [zorg] Add a step to run unit tests to the scripted LLDB builder

2016-06-08 Thread Ying Chen via lldb-commits
chying accepted this revision.
chying added a comment.
This revision is now accepted and ready to land.

thanks for making the changes, look good.


http://reviews.llvm.org/D21159



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


[Lldb-commits] [PATCH] D21164: Improve watchpoint error reporting specially for arm/aarch64 targets

2016-06-08 Thread Muhammad Omair Javaid via lldb-commits
omjavaid created this revision.
omjavaid added reviewers: tberghammer, labath.
omjavaid added a subscriber: lldb-commits.
Herald added subscribers: rengolin, aemerson.

This patch takes a few corrective measures to make sure we display meaningful 
reason against a watchpoint creation failure.

This is particularly important for the targets where we get to know dynamically 
about the availability of hardware watchpoint resources.

We are trying to check whether we have sufficient hardware watchpoint slots 
available before we go ahead and create a new watchpoint.

http://reviews.llvm.org/D21164

Files:
  source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp
  source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
  source/Target/Target.cpp

Index: source/Target/Target.cpp
===
--- source/Target/Target.cpp
+++ source/Target/Target.cpp
@@ -712,9 +712,20 @@
 if (rc.Success())
 {
 uint32_t num_current_watchpoints = 
target->GetWatchpointList().GetSize();
-if (num_current_watchpoints >= num_supported_hardware_watchpoints)
-error.SetErrorStringWithFormat("number of supported hardware 
watchpoints (%u) has been reached",
+if (num_supported_hardware_watchpoints == 0)
+{
+error.SetErrorStringWithFormat ("Target supports (%u) hardware 
watchpoint slots.\n",
+num_supported_hardware_watchpoints);
+return false;
+}
+else if (num_current_watchpoints >= num_supported_hardware_watchpoints)
+{
+error.SetErrorStringWithFormat("All (%u) hardware watchpoint slots 
already in use.\n",
num_supported_hardware_watchpoints);
+return false;
+}
+else
+return true;
 }
 return false;
 }
@@ -750,6 +761,9 @@
 error.SetErrorStringWithFormat ("invalid watchpoint type: %d", kind);
 }
 
+if (!CheckIfWatchpointsExhausted (this, error))
+return wp_sp;
+
 // Currently we only support one watchpoint per address, with total number
 // of watchpoints limited by the hardware which the inferior is running on.
 
@@ -798,11 +812,9 @@
 // Remove the said watchpoint from the list maintained by the target 
instance.
 m_watchpoint_list.Remove (wp_sp->GetID(), true);
 // See if we could provide more helpful error message.
-if (!CheckIfWatchpointsExhausted(this, error))
-{
-if (!OptionGroupWatchpoint::IsWatchSizeSupported(size))
-error.SetErrorStringWithFormat("watch size of %" PRIu64 " is 
not supported", (uint64_t)size);
-}
+if (!OptionGroupWatchpoint::IsWatchSizeSupported(size))
+error.SetErrorStringWithFormat("watch size of %" PRIu64 " is not 
supported", (uint64_t)size);
+
 wp_sp.reset();
 }
 else
Index: source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
===
--- source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
+++ source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
@@ -544,7 +544,7 @@
 error = ReadHardwareDebugInfo ();
 
 if (error.Fail())
-return LLDB_INVALID_INDEX32;
+return 0;
 
 return m_max_hwp_supported;
 }
Index: source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp
===
--- source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp
+++ source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp
@@ -592,7 +592,7 @@
 error = ReadHardwareDebugInfo ();
 
 if (error.Fail())
-return LLDB_INVALID_INDEX32;
+return 0;
 
 return m_max_hwp_supported;
 }


Index: source/Target/Target.cpp
===
--- source/Target/Target.cpp
+++ source/Target/Target.cpp
@@ -712,9 +712,20 @@
 if (rc.Success())
 {
 uint32_t num_current_watchpoints = target->GetWatchpointList().GetSize();
-if (num_current_watchpoints >= num_supported_hardware_watchpoints)
-error.SetErrorStringWithFormat("number of supported hardware watchpoints (%u) has been reached",
+if (num_supported_hardware_watchpoints == 0)
+{
+error.SetErrorStringWithFormat ("Target supports (%u) hardware watchpoint slots.\n",
+num_supported_hardware_watchpoints);
+return false;
+}
+else if (num_current_watchpoints >= num_supported_hardware_watchpoints)
+{
+error.SetErrorStringWithFormat("All (%u) hardware watchpoint slots already in use.\n",
num_supported_hardware_watchpoints);
+return false;
+}
+else
+return true;
 }
 return false;
 }
@@ -750,6 +761,9 @

Re: [Lldb-commits] [lldb] r270745 - Mark some arm-linux specific xfails marking bug entries

2016-06-08 Thread Omair Javaid via lldb-commits
On 26 May 2016 at 18:07, Pavel Labath  wrote:
> Omair,
>
> please be careful about using arm xfails. You are using too wide
> annotations and disabling tests even on configurations where they are
> known to pass.
>
>
> On 25 May 2016 at 19:48, Omair Javaid via lldb-commits
>  wrote:
>> Modified: 
>> lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/TestCallUserAnonTypedef.py
>> URL: 
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/TestCallUserAnonTypedef.py?rev=270745&r1=270744&r2=270745&view=diff
>> ==
>> --- 
>> lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/TestCallUserAnonTypedef.py
>>  (original)
>> +++ 
>> lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/TestCallUserAnonTypedef.py
>>  Wed May 25 13:48:39 2016
>> @@ -24,6 +24,7 @@ class TestExprLookupAnonStructTypedef(Te
>>  self.line = line_number('main.cpp', '// lldb testsuite break')
>>
>>  @expectedFailureAll(oslist=["windows"])
>> +@expectedFailureAll(oslist=['linux'], archs=['arm'], 
>> bugnumber="llvm.org/pr27868")
>
> These tests pass on soft float targets (e.g. android), so we should
> not disable it there. I think we should figure out a way to make it
> possible to disambiguate these. Right now it is possible to match
> based on the triple of the target using a regular expression, but
> maybe we could make that a bit easier. How about introducing a
> "environment" variable, so that you could specify 'environment =
> "eabihf"' or something like that?

I have these tests failing on arm-linux-gnueabi (armel) and
arm-linux-gnueabihf targets.

I think putting in ABI as an environment variable is the right idea. I
will see how I can separate out tests ABI based failures.

>
>> --- 
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/archives/TestBSDArchives.py
>>  (original)
>> +++ 
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/archives/TestBSDArchives.py
>>  Wed May 25 13:48:39 2016
>> @@ -21,6 +21,7 @@ class BSDArchivesTestCase(TestBase):
>>  self.line = line_number('a.c', '// Set file and line breakpoint 
>> inside a().')
>>
>>  @expectedFailureAll(oslist=["windows"], bugnumber="llvm.org/pr24527.  
>> Makefile.rules doesn't know how to build static libs on Windows")
>> +@expectedFailureAll(oslist=["linux"], archs=["arm"], 
>> bugnumber="llvm.org/pr27795")
>
> This test was passing in all configurations we are testing. The fact
> that you are getting a unicode error here tells me that the problem is
> probably specific to your setup (different locale or something). I
> don't think we should be disabling tests on all arm builds because of
> that. The problem is probably not that hard to fix, and it would be
> extremely valuable to weed out system dependencies like this in order
> to get more reproducible test results. Can you look into this ASAP?

There exists a discussion regarding this unicode error.
http://reviews.llvm.org/D16736

I seem to be getting this on all kind of hardware i have right now.

>
>> Modified: 
>> lldb/trunk/packages/Python/lldbsuite/test/linux/builtin_trap/TestBuiltinTrap.py
>> URL: 
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/linux/builtin_trap/TestBuiltinTrap.py?rev=270745&r1=270744&r2=270745&view=diff
>> ==
>> --- 
>> lldb/trunk/packages/Python/lldbsuite/test/linux/builtin_trap/TestBuiltinTrap.py
>>  (original)
>> +++ 
>> lldb/trunk/packages/Python/lldbsuite/test/linux/builtin_trap/TestBuiltinTrap.py
>>  Wed May 25 13:48:39 2016
>> @@ -25,6 +25,7 @@ class BuiltinTrapTestCase(TestBase):
>>
>>  @expectedFailureAll("llvm.org/pr15936", compiler="gcc", 
>> compiler_version=["<=","4.6"])
>>  @expectedFailureAll(archs="arm", compiler="gcc", triple=".*-android") # 
>> gcc generates incorrect linetable
>> +@expectedFailureAll(oslist=['linux'], archs=['arm'])
>>  @skipIfWindows
>>  def test_with_run_command(self):
>>  """Test that LLDB handles a function with __builtin_trap 
>> correctly."""
>>
>
> You're saying that the problem is due to gcc linetables. Then please
> specify compiler="gcc" here (if you know an approximate version range,
> even better).

I will correct this.

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


[Lldb-commits] [PATCH] D21159: [zorg] Add a step to run unit tests to the scripted LLDB builder

2016-06-08 Thread Pavel Labath via lldb-commits
labath created this revision.
labath added reviewers: chying, gkistanova.
labath added a subscriber: lldb-commits.

For the time being they are run with flunkOnFailure=False. If they prove to
be reliable. I will switch them to True.

http://reviews.llvm.org/D21159

Files:
  zorg/buildbot/builders/LLDBBuilder.py

Index: zorg/buildbot/builders/LLDBBuilder.py
===
--- zorg/buildbot/builders/LLDBBuilder.py
+++ zorg/buildbot/builders/LLDBBuilder.py
@@ -967,6 +967,13 @@
 
 # Test
 if runTest:
+f.addStep(LitTestCommand(name="run unit tests",
+ command=[pathSep + 'testUnit' + scriptExt],
+ description=["testing"],
+ descriptionDone=["unit test"],
+ flunkOnFailure=False,
+ warnOnFailure=False,
+ workdir='scripts'))
 getTestSteps(f, scriptExt, pathSep)
 # upload test traces
 getShellCommandStep(f, name='upload test traces',


Index: zorg/buildbot/builders/LLDBBuilder.py
===
--- zorg/buildbot/builders/LLDBBuilder.py
+++ zorg/buildbot/builders/LLDBBuilder.py
@@ -967,6 +967,13 @@
 
 # Test
 if runTest:
+f.addStep(LitTestCommand(name="run unit tests",
+ command=[pathSep + 'testUnit' + scriptExt],
+ description=["testing"],
+ descriptionDone=["unit test"],
+ flunkOnFailure=False,
+ warnOnFailure=False,
+ workdir='scripts'))
 getTestSteps(f, scriptExt, pathSep)
 # upload test traces
 getShellCommandStep(f, name='upload test traces',
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D21152: Hunt for unused memory properly when dealing with processes that can tell us about memory mappings

2016-06-08 Thread Sean Callanan via lldb-commits
spyffe created this revision.
spyffe added reviewers: tfiala, clayborg.
spyffe added a subscriber: lldb-commits.
spyffe set the repository for this revision to rL LLVM.

Right now the default initial address is 0x0, which is very problematic on 
embedded targets where that's the CPU's initialization vector.
To help in these scenarios, this patch uses the GetMemoryRegionInfo() API to 
find an appropriately-sized region.
It also sets better fallback defaults than 0x0 if all of the other approaches 
fail

Repository:
  rL LLVM

http://reviews.llvm.org/D21152

Files:
  source/Expression/IRMemoryMap.cpp

Index: source/Expression/IRMemoryMap.cpp
===
--- source/Expression/IRMemoryMap.cpp
+++ source/Expression/IRMemoryMap.cpp
@@ -13,8 +13,10 @@
 #include "lldb/Core/Log.h"
 #include "lldb/Core/Scalar.h"
 #include "lldb/Expression/IRMemoryMap.h"
+#include "lldb/Target/MemoryRegionInfo.h"
 #include "lldb/Target/Process.h"
 #include "lldb/Target/Target.h"
+#include "lldb/Utility/LLDBAssert.h"
 
 using namespace lldb_private;
 
@@ -47,23 +49,34 @@
 }
 
 lldb::addr_t
-IRMemoryMap::FindSpace (size_t size, bool zero_memory)
+IRMemoryMap::FindSpace (size_t size)
 {
+// The FindSpace algorithm's job is to find a region of memory that the
+// underlying process is unlikely to be using.
+//
+// The memory returned by this function will never be written to.  The only
+// point is that it should not shadow process memory if possible, so that
+// expressions processing real values from the process do not use the
+// wrong data.
+//
+// If the process can in fact allocate memory (CanJIT() lets us know this)
+// then this can be accomplished just be allocating memory in the inferior.
+// Then no guessing is required.
+
 lldb::TargetSP target_sp = m_target_wp.lock();
 lldb::ProcessSP process_sp = m_process_wp.lock();
+
+const bool is_alive = process_sp->IsAlive();
 
 lldb::addr_t ret = LLDB_INVALID_ADDRESS;
 if (size == 0)
 return ret;
 
-if (process_sp && process_sp->CanJIT() && process_sp->IsAlive())
+if (process_sp && process_sp->CanJIT() && is_alive)
 {
 Error alloc_error;
 
-if (!zero_memory)
-ret = process_sp->AllocateMemory(size, lldb::ePermissionsReadable | lldb::ePermissionsWritable, alloc_error);
-else
-ret = process_sp->CallocateMemory(size, lldb::ePermissionsReadable | lldb::ePermissionsWritable, alloc_error);
+ret = process_sp->AllocateMemory(size, lldb::ePermissionsReadable | lldb::ePermissionsWritable, alloc_error);
 
 if (!alloc_error.Success())
 return LLDB_INVALID_ADDRESS;
@@ -70,15 +83,103 @@
 else
 return ret;
 }
+
+// At this point we know that we need to hunt.
+//
+// First, go to the end of the existing allocations we've made if there are
+// any allocations.  Otherwise start at the beginning of memory.
 
-ret = 0;
-if (!m_allocations.empty())
+if (m_allocations.empty())
 {
+ret = 0x0;
+}
+else
+{
 auto back = m_allocations.rbegin();
 lldb::addr_t addr = back->first;
 size_t alloc_size = back->second.m_size;
 ret = llvm::alignTo(addr+alloc_size, 4096);
 }
+
+// Now, if it's possible to use the GetMemoryRegionInfo API to detect mapped
+// regions, walk forward through memory until a region is found that
+// has adequate space for our allocation.
+if (process_sp && is_alive)
+{
+const uint64_t end_of_memory = process_sp->GetAddressByteSize() == 8 ?
+0xull : 0xull;
+
+lldbassert(process_sp->GetAddressByteSize() == 4 || end_of_memory != 0xull);
+
+MemoryRegionInfo region_info;
+Error err = process_sp->GetMemoryRegionInfo(ret, region_info);
+if (err.Success())
+{
+while (true)
+{
+if (region_info.GetReadable() != MemoryRegionInfo::OptionalBool::eNo ||
+region_info.GetWritable() != MemoryRegionInfo::OptionalBool::eNo ||
+region_info.GetExecutable() != MemoryRegionInfo::OptionalBool::eNo)
+{
+if (region_info.GetRange().GetRangeEnd() - 1 >= end_of_memory)
+{
+ret = LLDB_INVALID_ADDRESS;
+break;
+}
+else
+{
+ret = region_info.GetRange().GetRangeEnd();
+}
+}
+else if (ret + size < region_info.GetRange().GetRangeEnd())
+{
+return ret;
+}
+else
+{
+// ret stays the same.  We just need to walk a bit further.
+}
+   

[Lldb-commits] [lldb] r272189 - Add a test for the failure described by pr28055. Mark it as xfail.

2016-06-08 Thread Jim Ingham via lldb-commits
Author: jingham
Date: Wed Jun  8 14:06:00 2016
New Revision: 272189

URL: http://llvm.org/viewvc/llvm-project?rev=272189&view=rev
Log:
Add a test for the failure described by pr28055.  Mark it as xfail.

Added:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_commands/command/watchpoint_command.py
Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_commands/command/TestWatchpointCommandPython.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_commands/command/TestWatchpointCommandPython.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_commands/command/TestWatchpointCommandPython.py?rev=272189&r1=272188&r2=272189&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_commands/command/TestWatchpointCommandPython.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_commands/command/TestWatchpointCommandPython.py
 Wed Jun  8 14:06:00 2016
@@ -87,3 +87,57 @@ class WatchpointPythonCommandTestCase(Te
 # The watchpoint command "forced" our global variable 'cookie' to 
become 777.
 self.expect("frame variable --show-globals cookie",
 substrs = ['(int32_t)', 'cookie = 777'])
+
+@skipIfFreeBSD # timing out on buildbot
+@expectedFailureAll(bugnumber="llvm.org/pr28055: continue in watchpoint 
commands disables the watchpoint")
+@expectedFailureAll(oslist=["windows"], bugnumber="llvm.org/pr24446: 
WINDOWS XFAIL TRIAGE - Watchpoints not supported on Windows")
+@expectedFailureAndroid(archs=['arm', 'aarch64']) # Watchpoints not 
supported
+@expectedFailureAll(oslist=["linux"], archs=["aarch64"], 
bugnumber="llvm.org/pr27710")
+def test_continue_in_watchpoint_command(self):
+"""Test continue in a watchpoint command."""
+self.build(dictionary=self.d)
+self.setTearDownCleanup(dictionary=self.d)
+
+exe = os.path.join(os.getcwd(), self.exe_name)
+self.runCmd("file " + exe, CURRENT_EXECUTABLE_SET)
+
+# Add a breakpoint to set a watchpoint when stopped on the breakpoint.
+lldbutil.run_break_set_by_file_and_line (self, None, self.line, 
num_expected_locations=1)
+#self.expect("breakpoint set -l %d" % self.line, BREAKPOINT_CREATED,
+#startstr = "Breakpoint created: 1: file ='%s', line = %d, 
locations = 1" %
+#   (self.source, self.line))#
+
+# Run the program.
+self.runCmd("run", RUN_SUCCEEDED)
+
+# We should be stopped again due to the breakpoint.
+# The stop reason of the thread should be breakpoint.
+self.expect("thread list", STOPPED_DUE_TO_BREAKPOINT,
+substrs = ['stopped',
+   'stop reason = breakpoint'])
+
+# Now let's set a write-type watchpoint for 'global'.
+self.expect("watchpoint set variable -w write global", 
WATCHPOINT_CREATED,
+substrs = ['Watchpoint created', 'size = 4', 'type = w',
+   '%s:%d' % (self.source, self.decl)])
+
+cmd_script_file = os.path.join(os.getcwd(), "watchpoint_command.py")
+self.runCmd("command script import '%s'"%(cmd_script_file))
+
+self.runCmd('watchpoint command add -F 
watchpoint_command.watchpoint_command')
+
+# List the watchpoint command we just added.
+self.expect("watchpoint command list 1",
+substrs = ['watchpoint_command.watchpoint_command'])
+
+self.runCmd("process continue")
+
+# We should be stopped again due to the watchpoint (write type).
+# The stop reason of the thread should be watchpoint.
+self.expect("thread backtrace", STOPPED_DUE_TO_WATCHPOINT,
+substrs = ['stop reason = watchpoint'])
+
+# We should have hit the watchpoint once, set cookie to 888, then 
continued to the
+# second hit and set it to 999
+self.expect("frame variable --show-globals cookie",
+substrs = ['(int32_t)', 'cookie = 999'])

Added: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_commands/command/watchpoint_command.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_commands/command/watchpoint_command.py?rev=272189&view=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_commands/command/watchpoint_command.py
 (added)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_commands/command/watchpoint_command.py
 Wed Jun  8 14:06:00 2016
@@ -0,0 +1,14 @@
+import lldb
+
+num_hits = 0
+def watchpoint_com