Re: [Lldb-commits] [PATCH] D16128: Fix TestProcessLaunch.test_environment_with_special_char for Python 3

[Pavel Labath via lldb-commits]

labath added a subscriber: labath.
labath requested changes to this revision.
labath added a reviewer: labath.
labath added a comment.
This revision now requires changes to proceed.

This will make the test fail on remote platforms, as the redirected file needs 
to be transferred in before you can check it (see TestQuoting for an example).

It sounds like we should come up with some guidelines wrt. using stdio in 
tests. I would like to use it as it is much simpler than using files, but I 
guess supporting that for windows, where you launch the inferior in a separate 
console window (which i very like btw) could be difficult (?). If we get rid of 
it, we might even kill two birds with one stone, as we have some stdio issues 
on linux as well (https://llvm.org/bugs/show_bug.cgi?id=25652). My favourite 
replacement for that would be inferior sticking whatever output in needs in a 
char[] variable and debugger reading it from there. This should hopefully work 
in all scenarios, as it does not depend on any external concepts.

Thoughts ?


http://reviews.llvm.org/D16128



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

Re: [Lldb-commits] [PATCH] D16049: [LLDB][MIPS] A small fix in GetBreakableLoadAddress() for MIPS

[Bhushan Attarde via lldb-commits]

bhushan updated this revision to Diff 44723.
bhushan added a comment.

This diff adds a testcase to test this patch.

The test gets all assembly instructions from the function and finds out the 
address of instruction in delay slot.
Then it tries to place a breakpoint on that address and verifies if breakpoint 
has been adjusted correctly. 
The breakpoint should get placed on branch instruction instead of delay slot 
instruction.


Repository:
  rL LLVM

http://reviews.llvm.org/D16049

Files:
  include/lldb/API/SBInstruction.h
  
packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_in_delayslot/Makefile
  
packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_in_delayslot/TestAvoidBreakpointInDelaySlot.py
  
packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_in_delayslot/main.c
  packages/Python/lldbsuite/test/lldbtest.py
  scripts/interface/SBInstruction.i
  source/API/SBInstruction.cpp

Index: packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_in_delayslot/main.c
===
--- /dev/null
+++ packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_in_delayslot/main.c
@@ -0,0 +1,21 @@
+#include 
+
+foo (int a, int b)
+{
+int c;
+if (a<=b)
+c=b-a;
+else
+c=b+a;
+return c;
+}
+
+int main()
+{
+int a=7, b=8, c;
+
+c = foo(a, b);
+
+return 0;
+}
+
Index: packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_in_delayslot/TestAvoidBreakpointInDelaySlot.py
===
--- /dev/null
+++ packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_in_delayslot/TestAvoidBreakpointInDelaySlot.py
@@ -0,0 +1,82 @@
+"""
+Test specific to MIPS 
+"""
+
+import os, time
+import re
+import unittest2
+import lldb
+import lldbsuite.test.lldbutil as lldbutil
+from lldbsuite.test.lldbtest import *
+
+class AvoidBreakpointInDelaySlotAPITestCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+@skipUnlessMips
+def test(self):
+self.build()
+exe = os.path.join(os.getcwd(), "a.out")
+self.expect("file " + exe,
+patterns = [ "Current executable set to .*a.out.*" ])
+
+# Create a target by the debugger.
+target = self.dbg.CreateTarget(exe)
+self.assertTrue(target, VALID_TARGET)
+
+breakpoint = target.BreakpointCreateByName('main', 'a.out')
+self.assertTrue(breakpoint and
+breakpoint.GetNumLocations() == 1,
+VALID_BREAKPOINT)
+
+# Now launch the process, and do not stop at entry point.
+process = target.LaunchSimple (None, None, self.get_process_working_directory())
+self.assertTrue(process, PROCESS_IS_VALID)
+
+list = target.FindFunctions('foo', lldb.eFunctionNameTypeAuto)
+self.assertTrue(list.GetSize() == 1)
+sc = list.GetContextAtIndex(0)
+self.assertTrue(sc.GetSymbol().GetName() == "foo")
+function = sc.GetFunction()
+self.assertTrue(function)
+self.function(function, target)
+
+def function (self, function, target):
+"""Iterate over instructions in function and place a breakpoint on delay slot instruction"""
+# Get the list of all instructions in the function
+insts = function.GetInstructions(target)
+print insts
+i = 0
+for inst in insts:
+if (inst.HasDelaySlot()):
+# Remember the address of branch instruction.
+branchinstaddress = inst.GetAddress().GetLoadAddress(target)
+
+# Get next instruction i.e delay slot instruction.
+delayinst = insts.GetInstructionAtIndex(i+1)
+delayinstaddr = delayinst.GetAddress().GetLoadAddress(target)
+
+# Set breakpoint on delay slot instruction
+breakpoint = target.BreakpointCreateByAddress(delayinstaddr)
+
+# Verify the breakpoint.
+self.assertTrue(breakpoint and
+breakpoint.GetNumLocations() == 1,
+VALID_BREAKPOINT)
+# Get the location from breakpoint
+location = breakpoint.GetLocationAtIndex(0)
+
+# Get the address where breakpoint is actually set.
+bpaddr = location.GetLoadAddress()
+		
+# Breakpoint address should be adjusted to the address of branch instruction.
+self.assertTrue(branchinstaddress ==  bpaddr)
+i += 1
+else:
+i += 1
+
+if __name__ == '__main__':
+import atexit
+lldb.SBDebugger.Initialize()
+atexit.register(lambda: lldb.SBDebugger.Terminate())
+unittest2.main()
Index: packages/Python/lldbsuite/test/functionalities/breakpoint/breakpoint_in_delayslot/Makefile
===

[Lldb-commits] [lldb] r257587 - [LLDB][MIPS] Fix TestDisassembleRawData.py

[Sagar Thakur via lldb-commits]

Author: slthakur
Date: Wed Jan 13 05:22:56 2016
New Revision: 257587

URL: http://llvm.org/viewvc/llvm-project?rev=257587&view=rev
Log:
[LLDB][MIPS] Fix TestDisassembleRawData.py

Patch by Nitesh Jain.

Summary: This patch adds check for the correctness of disassembling instruction 
for MIPS target.

Reviewers: emaste, clayborg, ovyalov
Subscribers: lldb-commits, mohit.bhakkad, sagar, bhushan, jaydeep
Differential: http://reviews.llvm.org/D15915

Modified:

lldb/trunk/packages/Python/lldbsuite/test/python_api/disassemble-raw-data/TestDisassembleRawData.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/python_api/disassemble-raw-data/TestDisassembleRawData.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/python_api/disassemble-raw-data/TestDisassembleRawData.py?rev=257587&r1=257586&r2=257587&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/python_api/disassemble-raw-data/TestDisassembleRawData.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/python_api/disassemble-raw-data/TestDisassembleRawData.py
 Wed Jan 13 05:22:56 2016
@@ -21,11 +21,18 @@ class DisassembleRawDataTestCase(TestBas
 def test_disassemble_raw_data(self):
 """Test disassembling raw bytes with the API."""
 # Create a target from the debugger.
-target = self.dbg.CreateTargetWithFileAndTargetTriple ("", "x86_64")
+arch = self.getArchitecture()
+if re.match("mips*el",arch):
+target = self.dbg.CreateTargetWithFileAndTargetTriple ("", 
"mipsel")
+raw_bytes = bytearray([0x21,0xf0, 0xa0, 0x03])
+elif re.match("mips",arch):
+target = self.dbg.CreateTargetWithFileAndTargetTriple ("", "mips")
+raw_bytes = bytearray([0x03,0xa0, 0xf0, 0x21])
+else:
+target = self.dbg.CreateTargetWithFileAndTargetTriple ("", 
"x86_64")
+raw_bytes = bytearray([0x48, 0x89, 0xe5])
+
 self.assertTrue(target, VALID_TARGET)
-
-raw_bytes = bytearray([0x48, 0x89, 0xe5])
-
 insts = target.GetInstructions(lldb.SBAddress(0, target), raw_bytes)
 
 inst = insts.GetInstructionAtIndex(0)
@@ -34,6 +41,9 @@ class DisassembleRawDataTestCase(TestBas
 print()
 print("Raw bytes:", [hex(x) for x in raw_bytes])
 print("Disassembled%s" % str(inst))
- 
-self.assertTrue (inst.GetMnemonic(target) == "movq")
-self.assertTrue (inst.GetOperands(target) == '%' + "rsp, " + '%' + 
"rbp")
+if re.match("mips",arch):
+self.assertTrue (inst.GetMnemonic(target) == "move")
+self.assertTrue (inst.GetOperands(target) == '$' + "fp, " + '$' + 
"sp")
+else:
+self.assertTrue (inst.GetMnemonic(target) == "movq")
+self.assertTrue (inst.GetOperands(target) == '%' + "rsp, " + '%' + 
"rbp")


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

Re: [Lldb-commits] [PATCH] D15915: [LLDB][MIPS] Fix TestDisassembleRawData.py

[Sagar Thakur via lldb-commits]

sagar closed this revision.
sagar added a comment.

Committed in revision 257587 on behalf of Nitesh Jain.


Repository:
  rL LLVM

http://reviews.llvm.org/D15915



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

Re: [Lldb-commits] [PATCH] D16107: Fix for Bug 25338

[Ravitheja Addepally via lldb-commits]

ravitheja added a comment.

Hi Tamas, a modified algorithm may work in this case for now, but this issue 
may still reoccur for some other Elf Format .


http://reviews.llvm.org/D16107



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

Re: [Lldb-commits] [PATCH] D16107: Fix for Bug 25338

[Tamas Berghammer via lldb-commits]

tberghammer added a comment.

Based on your description the vdso file itself looks like a valid elf file to 
me. If the ObjectFileELF plugin is buggy (it is certainly is as it can't handle 
the vdso) then I think we should fix that instead of building up a new approach 
just to work around one of our own bug.


http://reviews.llvm.org/D16107



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

Re: [Lldb-commits] [PATCH] D16107: Fix for Bug 25338

[Ravitheja Addepally via lldb-commits]

ravitheja added a comment.

Hi Oleyksiy, actually the problem is not with the Elf Format but its a problem 
with the ObjectFileElf itself which cannot handle reading from arbitrary 
offsets in the Elf. Now the ideal solution would be to fix that but as we had 
discussed last year we agreed to allocate more memory for the vdso. I could try 
to contain the complete fix in the ObjectFileElf but that may be 
counterproductive since it already buggy ?


http://reviews.llvm.org/D16107



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

[Lldb-commits] [lldb] r257603 - Silence an incorrect dwarf parsing warning

[Tamas Berghammer via lldb-commits]

Author: tberghammer
Date: Wed Jan 13 08:58:48 2016
New Revision: 257603

URL: http://llvm.org/viewvc/llvm-project?rev=257603&view=rev
Log:
Silence an incorrect dwarf parsing warning

We have a check what warns if the offset of a class member is greater
then or equal to the size of the class. The warning is valid in most
case but it is invalid when the last data member is a 0 size array
because in this case the member offset can be equal to the class size
(subject to alignment limitations).

This CL fixis LLDB to not print out a warning in this special case.

Modified:
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp

Modified: lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp?rev=257603&r1=257602&r2=257603&view=diff
==
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
(original)
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp Wed Jan 
13 08:58:48 2016
@@ -2928,7 +2928,7 @@ DWARFASTParserClang::ParseChildMembers (
 
 if (member_byte_offset >= 
parent_byte_size)
 {
-if (member_array_size != 1)
+if (member_array_size != 1 && 
(member_array_size != 0 || member_byte_offset > parent_byte_size))
 {
 module_sp->ReportError 
("0x%8.8" PRIx64 ": DW_TAG_member '%s' refers to type 0x%8.8" PRIx64 " which 
extends beyond the bounds of 0x%8.8" PRIx64,
 
die.GetID(),


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

Re: [Lldb-commits] [PATCH] D16107: Fix for Bug 25338

[Ravitheja Addepally via lldb-commits]

ravitheja added a comment.

Yes the vdso is fine, last year I did discuss this and we here decided that at 
the moment we can only offer this solution.


http://reviews.llvm.org/D16107



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

Re: [Lldb-commits] [PATCH] D16049: [LLDB][MIPS] A small fix in GetBreakableLoadAddress() for MIPS

[Zachary Turner via lldb-commits]

zturner added a comment.

In the future when you update the diff of a review, you need to base the diff 
against the original code, not against your first diff.  So the new diff should 
be a superset of your old diff.



Comment at: packages/Python/lldbsuite/test/lldbtest.py:1221-1234
@@ -1220,1 +1220,16 @@
 
+def skipUnlessMips(func):
+"""Decorate the item to skip tests that should be skipped only if not 
building for any of the mips targets."""
+if isinstance(func, type) and issubclass(func, unittest2.TestCase):
+raise Exception("@skipIfNotMips can only be used to decorate a test 
method")
+@wraps(func)
+def wrapper(*args, **kwargs):
+from unittest2 import case
+self = args[0]
+arch = self.getArchitecture()
+if not re.match('mips', arch):
+self.skipTest("skipping because this is a mips specific test")
+else:
+func(*args, **kwargs)
+return wrapper
+

You don't really need this, you can just use `@skipIf(archs=not_in(['mips']))`


Repository:
  rL LLVM

http://reviews.llvm.org/D16049



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

Re: [Lldb-commits] [PATCH] D16128: Fix TestProcessLaunch.test_environment_with_special_char for Python 3

[Zachary Turner via lldb-commits]

zturner added a comment.

Yea, supporting GetStdio is really difficult on Windows.  We might try to do it 
again someday.  Putting it in a char[] variable and reading the variable seems 
like a decent solution, I will try that.

There's lots of tests currently that redirect stdio, are those all broken on 
Linux currently?


http://reviews.llvm.org/D16128



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

Re: [Lldb-commits] [PATCH] D16128: Fix TestProcessLaunch.test_environment_with_special_char for Python 3

[Pavel Labath via lldb-commits]

labath added a comment.

In http://reviews.llvm.org/D16128#325804, @zturner wrote:

> Yea, supporting GetStdio is really difficult on Windows.  We might try to do 
> it again someday.  Putting it in a char[] variable and reading the variable 
> seems like a decent solution, I will try that.


Thanks.

> There's lots of tests currently that redirect stdio, are those all broken on 
> Linux currently?


The redirection works on linux, it's just not 100% reliable in tests. The thing 
is that inferior stdio arrives asynchronously wrt. everything else, so you 
really cannot be sure that by the time you do GetSTDOUT(), all output will be 
available. It works most of the time, but it fails in like ~0.1% of cases -- 
not much, but enough to be annoying when scrutinizing buildbot failures.


http://reviews.llvm.org/D16128



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

Re: [Lldb-commits] [PATCH] D16128: Fix TestProcessLaunch.test_environment_with_special_char for Python 3

[Pavel Labath via lldb-commits]

labath added a comment.

In http://reviews.llvm.org/D16128#325814, @labath wrote:

> > There's lots of tests currently that redirect stdio, are those all broken 
> > on Linux currently?
>
>
> The redirection works on linux, it's just not 100% reliable in tests. The 
> thing is that inferior stdio arrives asynchronously wrt. everything else, so 
> you really cannot be sure that by the time you do GetSTDOUT(), all output 
> will be available. It works most of the time, but it fails in like ~0.1% of 
> cases -- not much, but enough to be annoying when scrutinizing buildbot 
> failures.


Or, if you meant the other kind of redirection, in all tests that redirect 
stdio to a file, we have added a `if(remote) { platform.GetFile(...)}`, to 
retrieve the file from the remote side -- not really elegant and I would prefer 
using the `char[]` approach going forward.


http://reviews.llvm.org/D16128



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

[Lldb-commits] [lldb] r257644 - Fix an issue where scripted commands would not actually print any of their output if an immediate output file was set in the result object via a Python file object

[Enrico Granata via lldb-commits]

Author: enrico
Date: Wed Jan 13 12:11:45 2016
New Revision: 257644

URL: http://llvm.org/viewvc/llvm-project?rev=257644&view=rev
Log:
Fix an issue where scripted commands would not actually print any of their 
output if an immediate output file was set in the result object via a Python 
file object

Fixes rdar://24130303


Added:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script_immediate_output/

lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script_immediate_output/TestCommandScriptImmediateOutput.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script_immediate_output/custom_command.py
Modified:
lldb/trunk/include/lldb/Host/File.h
lldb/trunk/scripts/Python/python-typemaps.swig
lldb/trunk/source/Host/common/File.cpp
lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.h

Modified: lldb/trunk/include/lldb/Host/File.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Host/File.h?rev=257644&r1=257643&r2=257644&view=diff
==
--- lldb/trunk/include/lldb/Host/File.h (original)
+++ lldb/trunk/include/lldb/Host/File.h Wed Jan 13 12:11:45 2016
@@ -223,6 +223,9 @@ public:
 Error
 Close() override;
 
+void
+Clear ();
+
 Error
 Duplicate (const File &rhs);
 

Added: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script_immediate_output/TestCommandScriptImmediateOutput.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script_immediate_output/TestCommandScriptImmediateOutput.py?rev=257644&view=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script_immediate_output/TestCommandScriptImmediateOutput.py
 (added)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script_immediate_output/TestCommandScriptImmediateOutput.py
 Wed Jan 13 12:11:45 2016
@@ -0,0 +1,37 @@
+"""
+Test that LLDB correctly allows scripted commands to set an immediate output 
file
+"""
+
+from __future__ import print_function
+
+
+
+import os, time
+import lldb
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test.lldbpexpect import *
+
+class CommandScriptImmediateOutputTestCase (PExpectTest):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def setUp(self):
+# Call super's setUp().
+PExpectTest.setUp(self)
+
+@skipIfRemote # test not remote-ready llvm.org/pr24813
+@expectedFlakeyFreeBSD("llvm.org/pr25172 fails rarely on the buildbot")
+@expectedFlakeyLinux("llvm.org/pr25172")
+@expectedFailureWindows("llvm.org/pr22274: need a pexpect replacement for 
windows")
+def test_command_script_immediate_output (self):
+"""Test that LLDB correctly allows scripted commands to set an 
immediate output file."""
+self.launch(timeout=5)
+
+script = os.path.join(os.getcwd(), 'custom_command.py')
+prompt = "(lldb)"
+
+self.sendline('command script import %s' % script, patterns=[prompt])
+self.sendline('command script add -f custom_command.command_function 
mycommand', patterns=[prompt])
+self.sendline('mycommand', patterns='this is a test string, just a 
test string')
+self.sendline('command script delete mycommand', patterns=[prompt])
+self.quit(gracefully=False)

Added: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script_immediate_output/custom_command.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script_immediate_output/custom_command.py?rev=257644&view=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script_immediate_output/custom_command.py
 (added)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script_immediate_output/custom_command.py
 Wed Jan 13 12:11:45 2016
@@ -0,0 +1,8 @@
+from __future__ import print_function
+
+import sys
+
+def command_function(debugger, command, exe_ctx, result, internal_dict):
+result.SetImmediateOutputFile(sys.__stdout__)
+print('this is a test string, just a test string', file=result)
+

Modified: lldb/trunk/scripts/Python/python-typemaps.swig
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/Python/python-typemaps.swig?rev=257644&r1=257643&r2=257644&view=diff
==
--- lldb/trunk/scripts/Python/python-typemaps.swig (original)
+++ lldb/trunk/scripts/Python/python-typemaps.swig Wed Jan 13 12:11:45 2016
@@ -545,7 +545,9 @@
  return nullptr;
 
   $1 = file.GetStream();
-   }
+ 

Re: [Lldb-commits] [lldb] r257644 - Fix an issue where scripted commands would not actually print any of their output if an immediate output file was set in the result object via a Python file object

[Zachary Turner via lldb-commits]

On Wed, Jan 13, 2016 at 10:15 AM Enrico Granata via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

> +
> +class CommandScriptImmediateOutputTestCase (PExpectTest):
>
Does the bug that you were trying to fix occur only when using the
command_script.py file from the lldb command line?  If you load it from
within lldb via an LLDB command, does the problem still occur?  If the
problem you are fixing is not specific to the LLDB command line, I would
prefer if you write this not as a pexpect test.


> +
> +mydir = TestBase.compute_mydir(__file__)
> +
> +def setUp(self):
> +# Call super's setUp().
> +PExpectTest.setUp(self)
> +
> +@skipIfRemote # test not remote-ready llvm.org/pr24813
> +@expectedFlakeyFreeBSD("llvm.org/pr25172 fails rarely on the
> buildbot")
> +@expectedFlakeyLinux("llvm.org/pr25172")
>
Are these necessary?  The windows one is necessary (but not if you change
this to not being a pexpect test as I've requested above), but why are the
other ones necessary?
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r257644 - Fix an issue where scripted commands would not actually print any of their output if an immediate output file was set in the result object via a Python file object

[Enrico Granata via lldb-commits]

> On Jan 13, 2016, at 10:21 AM, Zachary Turner  wrote:
> 
> 
> On Wed, Jan 13, 2016 at 10:15 AM Enrico Granata via lldb-commits 
> mailto:lldb-commits@lists.llvm.org>> wrote:
> +
> +class CommandScriptImmediateOutputTestCase (PExpectTest):
> Does the bug that you were trying to fix occur only when using the 
> command_script.py file from the lldb command line?  If you load it from 
> within lldb via an LLDB command, does the problem still occur?  If the 
> problem you are fixing is not specific to the LLDB command line, I would 
> prefer if you write this not as a pexpect test.

I would love to not touch pexpect :-) But in this case, I can’t see a way 
around it. I am trying to detect whether some text is “physically” printed to 
stdout. And pexpect seems the most obvious straightforward way to get that to 
happen. Note that, in this bug, the result object is filled in correctly even 
if nothing gets printed, so looking at the result won’t quite cut it - it 
really needs to detect output to stdout

>  
> +
> +mydir = TestBase.compute_mydir(__file__)
> +
> +def setUp(self):
> +# Call super's setUp().
> +PExpectTest.setUp(self)
> +
> +@skipIfRemote # test not remote-ready llvm.org/pr24813 
> 
> +@expectedFlakeyFreeBSD("llvm.org/pr25172  fails 
> rarely on the buildbot")
> +@expectedFlakeyLinux("llvm.org/pr25172 ")
> Are these necessary?  The windows one is necessary (but not if you change 
> this to not being a pexpect test as I've requested above), but why are the 
> other ones necessary?


Do we support remote pexpect? As for FreeBSD and Linux, they might not be 
necessary, but I’d rather much remove them (or let the relevant platform 
owners) remove them in a separate commit

Thanks,
- Enrico
📩 egranata@.com ☎️ 27683

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

Re: [Lldb-commits] [lldb] r257644 - Fix an issue where scripted commands would not actually print any of their output if an immediate output file was set in the result object via a Python file object

[Zachary Turner via lldb-commits]

On Wed, Jan 13, 2016 at 10:25 AM Enrico Granata  wrote:

> On Jan 13, 2016, at 10:21 AM, Zachary Turner  wrote:
>
>
> On Wed, Jan 13, 2016 at 10:15 AM Enrico Granata via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
>> +
>> +class CommandScriptImmediateOutputTestCase (PExpectTest):
>>
> Does the bug that you were trying to fix occur only when using the
> command_script.py file from the lldb command line?  If you load it from
> within lldb via an LLDB command, does the problem still occur?  If the
> problem you are fixing is not specific to the LLDB command line, I would
> prefer if you write this not as a pexpect test.
>
>
> I would love to not touch pexpect :-) But in this case, I can’t see a way
> around it. I am trying to detect whether some text is “physically” printed
> to stdout. And pexpect seems the most obvious straightforward way to get
> that to happen. Note that, in this bug, the result object is filled in
> correctly even if nothing gets printed, so looking at the result won’t
> quite cut it - it really needs to detect output to stdout.
>
You're calling result.SetImmediateOutputFile(sys.__stdout__).  Wouldn't it
work to use a file on the file system here, and then you open that file and
look at it after running the commands?  It wouldn't work in remote cases,
but it already doesn't work on remote cases anyway (as you point out below)


>
>
>
>> +
>> +mydir = TestBase.compute_mydir(__file__)
>> +
>> +def setUp(self):
>> +# Call super's setUp().
>> +PExpectTest.setUp(self)
>> +
>> +@skipIfRemote # test not remote-ready llvm.org/pr24813
>> +@expectedFlakeyFreeBSD("llvm.org/pr25172 fails rarely on the
>> buildbot")
>> +@expectedFlakeyLinux("llvm.org/pr25172")
>>
> Are these necessary?  The windows one is necessary (but not if you change
> this to not being a pexpect test as I've requested above), but why are the
> other ones necessary?
>
>
> Do we support remote pexpect? As for FreeBSD and Linux, they might not be
> necessary, but I’d rather much remove them (or let the relevant platform
> owners) remove them in a separate commit
>
> No remote pexpect, so the @skipIfRemote probably needs to be there.  But I
think everyone should be checking in tests enabled by default in the widest
set of environments possible that you aren't completely sure are broken.
It should be up to the platform holders to disable broken tests, not to
enable working tests.  Because it's much easier to notice a broken test
going in than it is to notice a working test went in disabled (because
who's going to think to test it out?).
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r257644 - Fix an issue where scripted commands would not actually print any of their output if an immediate output file was set in the result object via a Python file object

[Enrico Granata via lldb-commits]

> On Jan 13, 2016, at 10:34 AM, Zachary Turner  wrote:
> 
> 
> 
> On Wed, Jan 13, 2016 at 10:25 AM Enrico Granata  > wrote:
>> On Jan 13, 2016, at 10:21 AM, Zachary Turner > > wrote:
>> 
>> 
>> On Wed, Jan 13, 2016 at 10:15 AM Enrico Granata via lldb-commits 
>> mailto:lldb-commits@lists.llvm.org>> wrote:
>> +
>> +class CommandScriptImmediateOutputTestCase (PExpectTest):
>> Does the bug that you were trying to fix occur only when using the 
>> command_script.py file from the lldb command line?  If you load it from 
>> within lldb via an LLDB command, does the problem still occur?  If the 
>> problem you are fixing is not specific to the LLDB command line, I would 
>> prefer if you write this not as a pexpect test.
> 
> I would love to not touch pexpect :-) But in this case, I can’t see a way 
> around it. I am trying to detect whether some text is “physically” printed to 
> stdout. And pexpect seems the most obvious straightforward way to get that to 
> happen. Note that, in this bug, the result object is filled in correctly even 
> if nothing gets printed, so looking at the result won’t quite cut it - it 
> really needs to detect output to stdout.
> You're calling result.SetImmediateOutputFile(sys.__stdout__).  Wouldn't it 
> work to use a file on the file system here, and then you open that file and 
> look at it after running the commands?  It wouldn't work in remote cases, but 
> it already doesn't work on remote cases anyway (as you point out below)
>  
> 
>>  
>> +
>> +mydir = TestBase.compute_mydir(__file__)
>> +
>> +def setUp(self):
>> +# Call super's setUp().
>> +PExpectTest.setUp(self)
>> +
>> +@skipIfRemote # test not remote-ready llvm.org/pr24813 
>> 
>> +@expectedFlakeyFreeBSD("llvm.org/pr25172  
>> fails rarely on the buildbot")
>> +@expectedFlakeyLinux("llvm.org/pr25172 ")
>> Are these necessary?  The windows one is necessary (but not if you change 
>> this to not being a pexpect test as I've requested above), but why are the 
>> other ones necessary?
> 
> 
> Do we support remote pexpect? As for FreeBSD and Linux, they might not be 
> necessary, but I’d rather much remove them (or let the relevant platform 
> owners) remove them in a separate commit
> 
> No remote pexpect, so the @skipIfRemote probably needs to be there.  But I 
> think everyone should be checking in tests enabled by default in the widest 
> set of environments possible that you aren't completely sure are broken.  It 
> should be up to the platform holders to disable broken tests, not to enable 
> working tests.  Because it's much easier to notice a broken test going in 
> than it is to notice a working test went in disabled (because who's going to 
> think to test it out?).


This is a fair point. I’ll enable those platforms in a subsequent commit ASAP

Thanks,
- Enrico
📩 egranata@.com ☎️ 27683

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

Re: [Lldb-commits] [lldb] r257644 - Fix an issue where scripted commands would not actually print any of their output if an immediate output file was set in the result object via a Python file object

[Zachary Turner via lldb-commits]

Thanks!  btw would having the command write its output to a file instead of
stdout solve the pexpect problme as well?

On Wed, Jan 13, 2016 at 11:22 AM Enrico Granata  wrote:

>
> On Jan 13, 2016, at 10:34 AM, Zachary Turner  wrote:
>
>
>
> On Wed, Jan 13, 2016 at 10:25 AM Enrico Granata 
> wrote:
>
>> On Jan 13, 2016, at 10:21 AM, Zachary Turner  wrote:
>>
>>
>> On Wed, Jan 13, 2016 at 10:15 AM Enrico Granata via lldb-commits <
>> lldb-commits@lists.llvm.org> wrote:
>>
>>> +
>>> +class CommandScriptImmediateOutputTestCase (PExpectTest):
>>>
>> Does the bug that you were trying to fix occur only when using the
>> command_script.py file from the lldb command line?  If you load it from
>> within lldb via an LLDB command, does the problem still occur?  If the
>> problem you are fixing is not specific to the LLDB command line, I would
>> prefer if you write this not as a pexpect test.
>>
>>
>> I would love to not touch pexpect :-) But in this case, I can’t see a way
>> around it. I am trying to detect whether some text is “physically” printed
>> to stdout. And pexpect seems the most obvious straightforward way to get
>> that to happen. Note that, in this bug, the result object is filled in
>> correctly even if nothing gets printed, so looking at the result won’t
>> quite cut it - it really needs to detect output to stdout.
>>
> You're calling result.SetImmediateOutputFile(sys.__stdout__).  Wouldn't it
> work to use a file on the file system here, and then you open that file and
> look at it after running the commands?  It wouldn't work in remote cases,
> but it already doesn't work on remote cases anyway (as you point out below)
>
>
>>
>>
>>
>>> +
>>> +mydir = TestBase.compute_mydir(__file__)
>>> +
>>> +def setUp(self):
>>> +# Call super's setUp().
>>> +PExpectTest.setUp(self)
>>> +
>>> +@skipIfRemote # test not remote-ready llvm.org/pr24813
>>> +@expectedFlakeyFreeBSD("llvm.org/pr25172 fails rarely on the
>>> buildbot")
>>> +@expectedFlakeyLinux("llvm.org/pr25172")
>>>
>> Are these necessary?  The windows one is necessary (but not if you change
>> this to not being a pexpect test as I've requested above), but why are the
>> other ones necessary?
>>
>>
>> Do we support remote pexpect? As for FreeBSD and Linux, they might not be
>> necessary, but I’d rather much remove them (or let the relevant platform
>> owners) remove them in a separate commit
>>
>> No remote pexpect, so the @skipIfRemote probably needs to be there.  But
> I think everyone should be checking in tests enabled by default in the
> widest set of environments possible that you aren't completely sure are
> broken.  It should be up to the platform holders to disable broken tests,
> not to enable working tests.  Because it's much easier to notice a broken
> test going in than it is to notice a working test went in disabled (because
> who's going to think to test it out?).
>
>
> This is a fair point. I’ll enable those platforms in a subsequent commit
> ASAP
>
>
> Thanks,
> *- Enrico*
> 📩 egranata@.com ☎️ 27683
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r257653 - Fixed a problem where the Xcode build put lldb's __init__.py in the wrong place.

[Sean Callanan via lldb-commits]

Author: spyffe
Date: Wed Jan 13 13:23:30 2016
New Revision: 257653

URL: http://llvm.org/viewvc/llvm-project?rev=257653&view=rev
Log:
Fixed a problem where the Xcode build put lldb's __init__.py in the wrong place.

Most of the time CONFIGURATION_BUILD_DIR and BUILT_PRODUCTS_DIR are the same,
but they are different in 'xcodebuild install' situations.  The file needs to be
put into BUILT_PRODUCTS_DIR or lldb's Python interface doesn't work when lldb is
built using 'xcodebuild install'.

Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj

Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lldb.xcodeproj/project.pbxproj?rev=257653&r1=257652&r2=257653&view=diff
==
--- lldb/trunk/lldb.xcodeproj/project.pbxproj (original)
+++ lldb/trunk/lldb.xcodeproj/project.pbxproj Wed Jan 13 13:23:30 2016
@@ -6300,7 +6300,7 @@
);
runOnlyForDeploymentPostprocessing = 0;
shellPath = /bin/sh;
-   shellScript = "sh 
$SRCROOT/scripts/finish-swig-wrapper-classes.sh $SRCROOT $TARGET_BUILD_DIR 
$CONFIGURATION_BUILD_DIR \"\"";
+   shellScript = "sh 
$SRCROOT/scripts/finish-swig-wrapper-classes.sh $SRCROOT $TARGET_BUILD_DIR 
$BUILT_PRODUCTS_DIR \"\"";
};
AF3059151B4B390800E25622 /* Run Script - remove unneeded 
Resources and Swift dirs from iOS LLDB.framework bundle */ = {
isa = PBXShellScriptBuildPhase;


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

Re: [Lldb-commits] [lldb] r257644 - Fix an issue where scripted commands would not actually print any of their output if an immediate output file was set in the result object via a Python file object

[Enrico Granata via lldb-commits]

> On Jan 13, 2016, at 11:26 AM, Zachary Turner  wrote:
> 
> Thanks!  btw would having the command write its output to a file instead of 
> stdout solve the pexpect problme as well?
> 

That’s possible - but I would need to play with it a little bit to convince 
myself that it really is a faithful reproduction of my original issue
It’ll take me a little while to get to it - stay tuned.

> On Wed, Jan 13, 2016 at 11:22 AM Enrico Granata  > wrote:
> 
>> On Jan 13, 2016, at 10:34 AM, Zachary Turner > > wrote:
>> 
>> 
>> 
>> On Wed, Jan 13, 2016 at 10:25 AM Enrico Granata > > wrote:
>>> On Jan 13, 2016, at 10:21 AM, Zachary Turner >> > wrote:
>>> 
>>> 
>>> On Wed, Jan 13, 2016 at 10:15 AM Enrico Granata via lldb-commits 
>>> mailto:lldb-commits@lists.llvm.org>> wrote:
>>> +
>>> +class CommandScriptImmediateOutputTestCase (PExpectTest):
>>> Does the bug that you were trying to fix occur only when using the 
>>> command_script.py file from the lldb command line?  If you load it from 
>>> within lldb via an LLDB command, does the problem still occur?  If the 
>>> problem you are fixing is not specific to the LLDB command line, I would 
>>> prefer if you write this not as a pexpect test.
>> 
>> I would love to not touch pexpect :-) But in this case, I can’t see a way 
>> around it. I am trying to detect whether some text is “physically” printed 
>> to stdout. And pexpect seems the most obvious straightforward way to get 
>> that to happen. Note that, in this bug, the result object is filled in 
>> correctly even if nothing gets printed, so looking at the result won’t quite 
>> cut it - it really needs to detect output to stdout.
>> You're calling result.SetImmediateOutputFile(sys.__stdout__).  Wouldn't it 
>> work to use a file on the file system here, and then you open that file and 
>> look at it after running the commands?  It wouldn't work in remote cases, 
>> but it already doesn't work on remote cases anyway (as you point out below)
>>  
>> 
>>>  
>>> +
>>> +mydir = TestBase.compute_mydir(__file__)
>>> +
>>> +def setUp(self):
>>> +# Call super's setUp().
>>> +PExpectTest.setUp(self)
>>> +
>>> +@skipIfRemote # test not remote-ready llvm.org/pr24813 
>>> 
>>> +@expectedFlakeyFreeBSD("llvm.org/pr25172  
>>> fails rarely on the buildbot")
>>> +@expectedFlakeyLinux("llvm.org/pr25172 ")
>>> Are these necessary?  The windows one is necessary (but not if you change 
>>> this to not being a pexpect test as I've requested above), but why are the 
>>> other ones necessary?
>> 
>> 
>> Do we support remote pexpect? As for FreeBSD and Linux, they might not be 
>> necessary, but I’d rather much remove them (or let the relevant platform 
>> owners) remove them in a separate commit
>> 
>> No remote pexpect, so the @skipIfRemote probably needs to be there.  But I 
>> think everyone should be checking in tests enabled by default in the widest 
>> set of environments possible that you aren't completely sure are broken.  It 
>> should be up to the platform holders to disable broken tests, not to enable 
>> working tests.  Because it's much easier to notice a broken test going in 
>> than it is to notice a working test went in disabled (because who's going to 
>> think to test it out?).
> 
> 
> This is a fair point. I’ll enable those platforms in a subsequent commit ASAP
> 
> 
> Thanks,
> - Enrico
> 📩 egranata@.com ☎️ 27683
> 


Thanks,
- Enrico
📩 egranata@.com ☎️ 27683

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

[Lldb-commits] [lldb] r257656 - Mark these tests on FreeBSD and Linux as non-flakey. We don't know that they are

[Enrico Granata via lldb-commits]

Author: enrico
Date: Wed Jan 13 13:29:52 2016
New Revision: 257656

URL: http://llvm.org/viewvc/llvm-project?rev=257656&view=rev
Log:
Mark these tests on FreeBSD and Linux as non-flakey. We don't know that they are

Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script_immediate_output/TestCommandScriptImmediateOutput.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script_immediate_output/TestCommandScriptImmediateOutput.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script_immediate_output/TestCommandScriptImmediateOutput.py?rev=257656&r1=257655&r2=257656&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script_immediate_output/TestCommandScriptImmediateOutput.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/command_script_immediate_output/TestCommandScriptImmediateOutput.py
 Wed Jan 13 13:29:52 2016
@@ -20,8 +20,6 @@ class CommandScriptImmediateOutputTestCa
 PExpectTest.setUp(self)
 
 @skipIfRemote # test not remote-ready llvm.org/pr24813
-@expectedFlakeyFreeBSD("llvm.org/pr25172 fails rarely on the buildbot")
-@expectedFlakeyLinux("llvm.org/pr25172")
 @expectedFailureWindows("llvm.org/pr22274: need a pexpect replacement for 
windows")
 def test_command_script_immediate_output (self):
 """Test that LLDB correctly allows scripted commands to set an 
immediate output file."""


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

[Lldb-commits] [PATCH] D16149: Delete char const** swig typemaps

[Zachary Turner via lldb-commits]

zturner created this revision.
zturner added a reviewer: granata.enrico.
zturner added a subscriber: lldb-commits.

We already have char** typemaps and they are exact copy-pastes.  No reason to 
have both, I tested this and diffed the generated code and it doesn't seem to 
be any different with this change.

http://reviews.llvm.org/D16149

Files:
  scripts/Python/python-typemaps.swig

Index: scripts/Python/python-typemaps.swig
===
--- scripts/Python/python-typemaps.swig
+++ scripts/Python/python-typemaps.swig
@@ -27,20 +27,6 @@
   }
 }
 
-%typemap(in) lldb::tid_t {
-  using namespace lldb_private;
-  if (PythonInteger::Check($input))
-  {
-PythonInteger py_int(PyRefType::Borrowed, $input);
-$1 = static_cast(py_int.GetInteger());
-  }
-  else
-  {
-PyErr_SetString(PyExc_ValueError, "Expecting an integer");
-return nullptr;
-  }
-}
-
 %typemap(typecheck) char ** {
   /* Check if is a list  */
   $1 = 1;
@@ -76,68 +62,19 @@
   $result = list.release();
 }
 
-%typemap(in) char const ** {
-  /* Check if is a list  */
-  using namespace lldb_private;
-  if (PythonList::Check($input)) {
-PythonList py_list(PyRefType::Borrowed, $input);
-int size = py_list.GetSize();
-
-$1 = (char**)malloc((size+1)*sizeof(char*));
-for (int i = 0; i < size; i++) {
-  auto py_str = py_list.GetItemAtIndex(i).AsType();
-  if (!py_str.IsAllocated()) {
-PyErr_SetString(PyExc_TypeError,"list must contain strings");
-free($1);
-return nullptr;
-  }
-  $1[i] = const_cast(py_str.GetString().data());
-}
-
-$1[size] = 0;
-  } else if ($input == Py_None) {
-$1 = nullptr;
-  } else {
-PyErr_SetString(PyExc_TypeError,"not a list");
-return nullptr;
-  }
-}
 
-%typemap(typecheck) char const ** {
+%typemap(in) lldb::tid_t {
   using namespace lldb_private;
-  /* Check if is a list  */
-  $1 = 1;
-  if (PythonList::Check($input)) {
-PythonList list(PyRefType::Borrowed, $input);
-int size = list.GetSize();
-int i = 0;
-for (i = 0; i < size; i++) {
-  PythonString s = list.GetItemAtIndex(i).AsType();
-  if (!s.IsAllocated()) { $1 = 0; }
-}
+  if (PythonInteger::Check($input))
+  {
+PythonInteger py_int(PyRefType::Borrowed, $input);
+$1 = static_cast(py_int.GetInteger());
   }
   else
   {
-$1 = ( ($input == Py_None) ? 1 : 0);
-  }
-}
-
-%typemap(freearg) char const ** {
-  free((char *) $1);
-}
-
-%typemap(out) char const ** {
-  int len;
-  int i;
-  len = 0;
-  while ($1[len]) len++;
-  using namespace lldb_private;
-  PythonList list(len);
-  for (i = 0; i < len; i++) {
-PythonString str($1[i]);
-list.SetItemAtIndex(i, str);
+PyErr_SetString(PyExc_ValueError, "Expecting an integer");
+return nullptr;
   }
-  $result = list.release();
 }
 
 /* Typemap definitions to allow SWIG to properly handle char buffer. */
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D16150: Fix project name conflict for MSBuild

[Jonathan Meier via lldb-commits]

jonathanmeier created this revision.
jonathanmeier added a reviewer: zturner.
jonathanmeier added a subscriber: lldb-commits.

CMake allows case sensitive folder naming when setting the folder property of a 
target. However MSBuild doesn't like that. It complains about having two 
projects named the same when trying to compile the solution and aborts. 
(Solution file error MSB5004: The solution file has two projects named "lldb 
tests")

In lldb/unittests/CMakeLists.txt a folder "LLDB tests" is defined and in 
lldb/lit/CMakeLists.txt a folder "lldb tests" is defined.

Renaming "lldb tests" to "LLDB tests" in lldb/lit/CMakeLists.txt fixes the 
problem.

http://reviews.llvm.org/D16150

Files:
  lit/CMakeLists.txt

Index: lit/CMakeLists.txt
===
--- lit/CMakeLists.txt
+++ lit/CMakeLists.txt
@@ -33,4 +33,4 @@
   DEPENDS ${LLDB_TEST_DEPS}
   )
 
-set_target_properties(check-lldb-unit PROPERTIES FOLDER "lldb tests")
+set_target_properties(check-lldb-unit PROPERTIES FOLDER "LLDB tests")


Index: lit/CMakeLists.txt
===
--- lit/CMakeLists.txt
+++ lit/CMakeLists.txt
@@ -33,4 +33,4 @@
   DEPENDS ${LLDB_TEST_DEPS}
   )
 
-set_target_properties(check-lldb-unit PROPERTIES FOLDER "lldb tests")
+set_target_properties(check-lldb-unit PROPERTIES FOLDER "LLDB tests")
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D16107: Fix for Bug 25338

[Oleksiy Vyalov via lldb-commits]

ovyalov added a comment.

If vdso bug pertains to ELF format then it looks reasonable to keep the fix 
within ObjectFileELF.
I experimented a while ago with making ObjectFileELF to read from arbitrary 
offsets - please see http://reviews.llvm.org/D16151 as reflection of this idea 
(patch is pretty old and cannot be applied as-is).
Please take a look into it and let us know whether such approach may solve vdso 
problem.


http://reviews.llvm.org/D16107



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

Re: [Lldb-commits] [PATCH] D16150: Fix project name conflict for MSBuild

[Zachary Turner via lldb-commits]

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

looks good, thanks


http://reviews.llvm.org/D16150



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

Re: [Lldb-commits] [PATCH] D16149: Delete char const** swig typemaps

[Enrico Granata via lldb-commits]

granata.enrico added a comment.

Did you mean to delete the tid_t typemap as well?

Assuming there truly are identical typemaps and these are just copies, and 
everything works just as well when they are removed, I have no objection


http://reviews.llvm.org/D16149



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

Re: [Lldb-commits] [PATCH] D16149: Delete char const** swig typemaps

[Zachary Turner via lldb-commits]

zturner added a comment.

I just moved tid to the bottom because it was in the middle of the in, out, and 
typecheck versions of the char** typemap.  So I wanted to group them all 
together.

Anyway, yea this didn't seem too controversial to me but I figured I'd throw it 
up here for review in case you knew of some quirk of swig with regards to 
typematching and constness.  But yea, I tested it and the generated code is 
semantically identical.

If anything breaks it will probably be due to a swig version difference, so let 
me know after I commit since I'm using 3.x


http://reviews.llvm.org/D16149



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

Re: [Lldb-commits] [PATCH] D16149: Delete char const** swig typemaps

[Enrico Granata via lldb-commits]

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

Ops, sorry, didn't notice the tid_t type map was actually added back later on 
in the patch. My bad.

I'm going to accept this for now, with the caveat that we'll need to work 
through it and possibly revert if it breaks on our SWIG. Unlikely that that 
happens though.


http://reviews.llvm.org/D16149



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

[Lldb-commits] [lldb] r257671 - Fix some compiler warnings with MSVC 2015.

[Zachary Turner via lldb-commits]

Author: zturner
Date: Wed Jan 13 15:22:00 2016
New Revision: 257671

URL: http://llvm.org/viewvc/llvm-project?rev=257671&view=rev
Log:
Fix some compiler warnings with MSVC 2015.

Modified:
lldb/trunk/source/DataFormatters/StringPrinter.cpp
lldb/trunk/source/Expression/ExpressionSourceCode.cpp
lldb/trunk/source/Plugins/ExpressionParser/Go/GoAST.h
lldb/trunk/source/Plugins/Instruction/MIPS/EmulateInstructionMIPS.cpp
lldb/trunk/source/Plugins/OperatingSystem/Go/OperatingSystemGo.cpp
lldb/trunk/source/Target/Process.cpp

Modified: lldb/trunk/source/DataFormatters/StringPrinter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/DataFormatters/StringPrinter.cpp?rev=257671&r1=257670&r2=257671&view=diff
==
--- lldb/trunk/source/DataFormatters/StringPrinter.cpp (original)
+++ lldb/trunk/source/DataFormatters/StringPrinter.cpp Wed Jan 13 15:22:00 2016
@@ -207,7 +207,7 @@ GetPrintableImplhttp://llvm.org/viewvc/llvm-project/lldb/trunk/source/Expression/ExpressionSourceCode.cpp?rev=257671&r1=257670&r2=257671&view=diff
==
--- lldb/trunk/source/Expression/ExpressionSourceCode.cpp (original)
+++ lldb/trunk/source/Expression/ExpressionSourceCode.cpp Wed Jan 13 15:22:00 
2016
@@ -118,6 +118,8 @@ public:
 return false;
 else
 return true;
+default:
+return false;
 }
 }
 

Modified: lldb/trunk/source/Plugins/ExpressionParser/Go/GoAST.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ExpressionParser/Go/GoAST.h?rev=257671&r1=257670&r2=257671&view=diff
==
--- lldb/trunk/source/Plugins/ExpressionParser/Go/GoAST.h (original)
+++ lldb/trunk/source/Plugins/ExpressionParser/Go/GoAST.h Wed Jan 13 15:22:00 
2016
@@ -2764,6 +2764,7 @@ R GoASTExpr::Visit(V* v) const
 return v->VisitUnaryExpr(llvm::cast(this));
 default:
 assert(false && "Invalid kind");
+return R();
 }
 }
 

Modified: lldb/trunk/source/Plugins/Instruction/MIPS/EmulateInstructionMIPS.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Instruction/MIPS/EmulateInstructionMIPS.cpp?rev=257671&r1=257670&r2=257671&view=diff
==
--- lldb/trunk/source/Plugins/Instruction/MIPS/EmulateInstructionMIPS.cpp 
(original)
+++ lldb/trunk/source/Plugins/Instruction/MIPS/EmulateInstructionMIPS.cpp Wed 
Jan 13 15:22:00 2016
@@ -1142,7 +1142,7 @@ EmulateInstructionMIPS::Emulate_SWSP (ll
 // We look for sp based non-volatile register stores.
 if (base == dwarf_sp_mips && nonvolatile_reg_p (src))
 {
-RegisterInfo reg_info_src;
+RegisterInfo reg_info_src = {};
 Context context;
 RegisterValue data_src;
 context.type = eContextPushRegisterOnStack;

Modified: lldb/trunk/source/Plugins/OperatingSystem/Go/OperatingSystemGo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/OperatingSystem/Go/OperatingSystemGo.cpp?rev=257671&r1=257670&r2=257671&view=diff
==
--- lldb/trunk/source/Plugins/OperatingSystem/Go/OperatingSystemGo.cpp 
(original)
+++ lldb/trunk/source/Plugins/OperatingSystem/Go/OperatingSystemGo.cpp Wed Jan 
13 15:22:00 2016
@@ -506,7 +506,7 @@ OperatingSystemGo::Goroutine
 OperatingSystemGo::CreateGoroutineAtIndex(uint64_t idx, Error &err)
 {
 err.Clear();
-Goroutine result;
+Goroutine result = {};
 ValueObjectSP g = m_allg_sp->GetSyntheticArrayMember(idx, 
true)->Dereference(err);
 if (err.Fail())
 {

Modified: lldb/trunk/source/Target/Process.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/Process.cpp?rev=257671&r1=257670&r2=257671&view=diff
==
--- lldb/trunk/source/Target/Process.cpp (original)
+++ lldb/trunk/source/Target/Process.cpp Wed Jan 13 15:22:00 2016
@@ -1504,6 +1504,8 @@ Process::IsAlive ()
 case eStateCrashed:
 case eStateSuspended:
 return true;
+default:
+return false;
 }
 }
 


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

[Lldb-commits] [lldb] r257669 - Fix TestProcessLaunch for Python 3.

[Zachary Turner via lldb-commits]

Author: zturner
Date: Wed Jan 13 15:21:49 2016
New Revision: 257669

URL: http://llvm.org/viewvc/llvm-project?rev=257669&view=rev
Log:
Fix TestProcessLaunch for Python 3.

There were a number of problems preventing this from working:

1. The SWIG typemaps for converting Python lists to and from C++
   arrays were not updated for Python 3.  So they were doing things
   like PyString_Check instead of using the PythonString from
   PythonDataObjects.
2. ProcessLauncherWindows was ignoring the environment completely.
   So any test that involved launching an inferior with any kind
   of environment variable would have failed.
3. The test itself was using process.GetSTDOUT(), which isn't
   implemented on Windows.  So this was changed to save the
   value of the environment variable in a local variable and
   have the debugger look at the value of the variable.

Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/process_launch/TestProcessLaunch.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/process_launch/print_env.cpp
lldb/trunk/scripts/Python/python-typemaps.swig
lldb/trunk/source/Host/windows/ProcessLauncherWindows.cpp

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/process_launch/TestProcessLaunch.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/process_launch/TestProcessLaunch.py?rev=257669&r1=257668&r2=257669&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/process_launch/TestProcessLaunch.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/process_launch/TestProcessLaunch.py
 Wed Jan 13 15:21:49 2016
@@ -4,12 +4,15 @@ Test lldb process launch flags.
 
 from __future__ import print_function
 
+import copy
+import os
+import time
 
-
-import os, time
 import lldb
 from lldbsuite.test.lldbtest import *
 
+import six
+
 class ProcessLaunchTestCase(TestBase):
 
 mydir = TestBase.compute_mydir(__file__)
@@ -17,9 +20,18 @@ class ProcessLaunchTestCase(TestBase):
 def setUp(self):
 # Call super's setUp().
 TestBase.setUp(self)
+self.stdout_redirect_file = 'lldb-stdout-redirect.txt'
 # disable "There is a running process, kill it and restart?" prompt
 self.runCmd("settings set auto-confirm true")
-self.addTearDownHook(lambda: self.runCmd("settings clear 
auto-confirm"))
+def tearDown(self):
+self.runCmd("settings clear auto-confirm")
+
+try:
+os.unlink(self.stdout_redirect_file)
+except:
+pass
+
+super().tearDown()
 
 @not_remote_testsuite_ready
 def test_io (self):
@@ -180,8 +192,9 @@ class ProcessLaunchTestCase(TestBase):
 self.fail(err_msg)
 
 def test_environment_with_special_char (self):
-"""Test that environment variables containing '*' and '}' are 
communicated correctly to the lldb-server."""
-d = {'CXX_SOURCES' : 'print_env.cpp'}
+"""Test that environment variables containing '*' and '}' are handled 
correctly by the inferior."""
+source = 'print_env.cpp'
+d = {'CXX_SOURCES' : source}
 self.build(dictionary=d)
 self.setTearDownCleanup(d)
 exe = os.path.join (os.getcwd(), "a.out")
@@ -189,19 +202,19 @@ class ProcessLaunchTestCase(TestBase):
 evil_var = 'INIT*MIDDLE}TAIL'
 
 target = self.dbg.CreateTarget(exe)
+main_source_spec = lldb.SBFileSpec(source)
+breakpoint = target.BreakpointCreateBySourceRegex('// Set breakpoint 
here.', main_source_spec)
+
 process = target.LaunchSimple(None, ['EVIL=' + evil_var], 
self.get_process_working_directory())
-self.assertEqual(process.GetState(), lldb.eStateExited, PROCESS_EXITED)
+self.assertEqual(process.GetState(), lldb.eStateStopped, 
PROCESS_STOPPED)
 
-out = process.GetSTDOUT(len(evil_var))
-self.assertIsNotNone(out, "Encountered an error reading the process's 
output")
+threads = lldbutil.get_threads_stopped_at_breakpoint(process, 
breakpoint)
+self.assertEqual(len(threads), 1)
+frame = threads[0].GetFrameAtIndex(0)
+sbvalue = frame.EvaluateExpression("evil")
+value = sbvalue.GetSummary().strip('"')
 
-out = out[:len(evil_var)]
-if out != evil_var:
-self.fail('The environment variable was mis-coded: %s\n' % 
repr(out))
-
-newline = process.GetSTDOUT(1)
-self.assertIsNotNone(newline, "Encountered an error reading the 
process's output")
-
-newline = newline[0]
-if newline != '\r' and newline != '\n':
-self.fail('Garbage at end of environment variable')
+self.assertEqual(value, evil_var)
+process.Continue()
+self.assertEqual(process.GetState(), lldb.eStateExited, PROCESS_EXITED)
+pass
\ No newline at end

[Lldb-commits] [lldb] r257670 - Get rid of const char** typemaps.

[Zachary Turner via lldb-commits]

Author: zturner
Date: Wed Jan 13 15:21:54 2016
New Revision: 257670

URL: http://llvm.org/viewvc/llvm-project?rev=257670&view=rev
Log:
Get rid of const char** typemaps.

We already have char** typemaps which were near copy-pastes of
the const char** versions.  This way we have only one version that
works for both.

Modified:
lldb/trunk/scripts/Python/python-typemaps.swig

Modified: lldb/trunk/scripts/Python/python-typemaps.swig
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/Python/python-typemaps.swig?rev=257670&r1=257669&r2=257670&view=diff
==
--- lldb/trunk/scripts/Python/python-typemaps.swig (original)
+++ lldb/trunk/scripts/Python/python-typemaps.swig Wed Jan 13 15:21:54 2016
@@ -27,20 +27,6 @@
   }
 }
 
-%typemap(in) lldb::tid_t {
-  using namespace lldb_private;
-  if (PythonInteger::Check($input))
-  {
-PythonInteger py_int(PyRefType::Borrowed, $input);
-$1 = static_cast(py_int.GetInteger());
-  }
-  else
-  {
-PyErr_SetString(PyExc_ValueError, "Expecting an integer");
-return nullptr;
-  }
-}
-
 %typemap(typecheck) char ** {
   /* Check if is a list  */
   $1 = 1;
@@ -76,68 +62,19 @@
   $result = list.release();
 }
 
-%typemap(in) char const ** {
-  /* Check if is a list  */
-  using namespace lldb_private;
-  if (PythonList::Check($input)) {
-PythonList py_list(PyRefType::Borrowed, $input);
-int size = py_list.GetSize();
 
-$1 = (char**)malloc((size+1)*sizeof(char*));
-for (int i = 0; i < size; i++) {
-  auto py_str = py_list.GetItemAtIndex(i).AsType();
-  if (!py_str.IsAllocated()) {
-PyErr_SetString(PyExc_TypeError,"list must contain strings");
-free($1);
-return nullptr;
-  }
-  $1[i] = const_cast(py_str.GetString().data());
-}
-
-$1[size] = 0;
-  } else if ($input == Py_None) {
-$1 = nullptr;
-  } else {
-PyErr_SetString(PyExc_TypeError,"not a list");
-return nullptr;
-  }
-}
-
-%typemap(typecheck) char const ** {
+%typemap(in) lldb::tid_t {
   using namespace lldb_private;
-  /* Check if is a list  */
-  $1 = 1;
-  if (PythonList::Check($input)) {
-PythonList list(PyRefType::Borrowed, $input);
-int size = list.GetSize();
-int i = 0;
-for (i = 0; i < size; i++) {
-  PythonString s = list.GetItemAtIndex(i).AsType();
-  if (!s.IsAllocated()) { $1 = 0; }
-}
+  if (PythonInteger::Check($input))
+  {
+PythonInteger py_int(PyRefType::Borrowed, $input);
+$1 = static_cast(py_int.GetInteger());
   }
   else
   {
-$1 = ( ($input == Py_None) ? 1 : 0);
-  }
-}
-
-%typemap(freearg) char const ** {
-  free((char *) $1);
-}
-
-%typemap(out) char const ** {
-  int len;
-  int i;
-  len = 0;
-  while ($1[len]) len++;
-  using namespace lldb_private;
-  PythonList list(len);
-  for (i = 0; i < len; i++) {
-PythonString str($1[i]);
-list.SetItemAtIndex(i, str);
+PyErr_SetString(PyExc_ValueError, "Expecting an integer");
+return nullptr;
   }
-  $result = list.release();
 }
 
 /* Typemap definitions to allow SWIG to properly handle char buffer. */


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

Re: [Lldb-commits] [PATCH] D16150: Fix project name conflict for MSBuild

[Jonathan Meier via lldb-commits]

jonathanmeier added a comment.

Could you please commit that for me? I don't have write access to the 
repository.


http://reviews.llvm.org/D16150



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

Re: [Lldb-commits] [PATCH] D16150: Fix project name conflict for MSBuild

[Zachary Turner via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL257684: Rename MSVC top-level folder to avoid name 
collision. (authored by zturner).

Changed prior to commit:
  http://reviews.llvm.org/D16150?vs=44775&id=44787#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D16150

Files:
  lldb/trunk/lit/CMakeLists.txt

Index: lldb/trunk/lit/CMakeLists.txt
===
--- lldb/trunk/lit/CMakeLists.txt
+++ lldb/trunk/lit/CMakeLists.txt
@@ -33,4 +33,4 @@
   DEPENDS ${LLDB_TEST_DEPS}
   )
 
-set_target_properties(check-lldb-unit PROPERTIES FOLDER "lldb tests")
+set_target_properties(check-lldb-unit PROPERTIES FOLDER "LLDB tests")


Index: lldb/trunk/lit/CMakeLists.txt
===
--- lldb/trunk/lit/CMakeLists.txt
+++ lldb/trunk/lit/CMakeLists.txt
@@ -33,4 +33,4 @@
   DEPENDS ${LLDB_TEST_DEPS}
   )
 
-set_target_properties(check-lldb-unit PROPERTIES FOLDER "lldb tests")
+set_target_properties(check-lldb-unit PROPERTIES FOLDER "LLDB tests")
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r257684 - Rename MSVC top-level folder to avoid name collision.

[Zachary Turner via lldb-commits]

Author: zturner
Date: Wed Jan 13 16:00:44 2016
New Revision: 257684

URL: http://llvm.org/viewvc/llvm-project?rev=257684&view=rev
Log:
Rename MSVC top-level folder to avoid name collision.

If you have two folders with the same name but different cases,
MSBuild gets confused and generates an error when building
from within Visual Studio.

This patch renames it so that the cases of all folders named
"LLDB tests" match.

Patch by Jonathan Meier
Differential Revision: http://reviews.llvm.org/D16150

Modified:
lldb/trunk/lit/CMakeLists.txt

Modified: lldb/trunk/lit/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/CMakeLists.txt?rev=257684&r1=257683&r2=257684&view=diff
==
--- lldb/trunk/lit/CMakeLists.txt (original)
+++ lldb/trunk/lit/CMakeLists.txt Wed Jan 13 16:00:44 2016
@@ -33,4 +33,4 @@ add_lit_testsuite(check-lldb-unit "Runni
   DEPENDS ${LLDB_TEST_DEPS}
   )
 
-set_target_properties(check-lldb-unit PROPERTIES FOLDER "lldb tests")
+set_target_properties(check-lldb-unit PROPERTIES FOLDER "LLDB tests")


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

[Lldb-commits] [PATCH] D16155: possible ambigous resolution of clang::ArrayType/llvm::ArrayType in ClangAstContext

[Luke Drummond via lldb-commits]

ldrumm created this revision.
ldrumm added a reviewer: spyffe.
ldrumm added a subscriber: lldb-commits.

source/Symbol/ClangASTContext.cpp has `using namespace llvm; using namespace 
clang;` Both 
[llvm](http://llvm.org/docs/doxygen/html/classllvm_1_1ArrayType.html) and 
[clang](http://clang.llvm.org/doxygen/classclang_1_1ArrayType.html) have an 
`ArrayType` class, which can cause resolution to fail when llvm headers that 
are implicitly included name this  type.

http://reviews.llvm.org/D16155

Files:
  source/Symbol/ClangASTContext.cpp

Index: source/Symbol/ClangASTContext.cpp
===
--- source/Symbol/ClangASTContext.cpp
+++ source/Symbol/ClangASTContext.cpp
@@ -2105,14 +2105,14 @@
 if (element_count == 0)
 {
 return CompilerType (ast, ast->getIncompleteArrayType 
(GetQualType(element_type),
-   
ArrayType::Normal,
+   
clang::ArrayType::Normal,
0));
 }
 else
 {
 return CompilerType (ast, ast->getConstantArrayType 
(GetQualType(element_type),
  
ap_element_count,
- 
ArrayType::Normal,
+ 
clang::ArrayType::Normal,
  0));
 }
 }


Index: source/Symbol/ClangASTContext.cpp
===
--- source/Symbol/ClangASTContext.cpp
+++ source/Symbol/ClangASTContext.cpp
@@ -2105,14 +2105,14 @@
 if (element_count == 0)
 {
 return CompilerType (ast, ast->getIncompleteArrayType (GetQualType(element_type),
-   ArrayType::Normal,
+   clang::ArrayType::Normal,
0));
 }
 else
 {
 return CompilerType (ast, ast->getConstantArrayType (GetQualType(element_type),
  ap_element_count,
- ArrayType::Normal,
+ clang::ArrayType::Normal,
  0));
 }
 }
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D16155: possible ambiguous resolution of clang::ArrayType/llvm::ArrayType in ClangAstContext

[Sean Callanan via lldb-commits]

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

This looks fine.  Thanks for paying attention to the details!


http://reviews.llvm.org/D16155



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

[Lldb-commits] [lldb] r257690 - Revert changes to TestProcessLaunch.py as they are breaking a build.

[Zachary Turner via lldb-commits]

Author: zturner
Date: Wed Jan 13 16:32:31 2016
New Revision: 257690

URL: http://llvm.org/viewvc/llvm-project?rev=257690&view=rev
Log:
Revert changes to TestProcessLaunch.py as they are breaking a build.

Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/process_launch/TestProcessLaunch.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/process_launch/print_env.cpp

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/process_launch/TestProcessLaunch.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/process_launch/TestProcessLaunch.py?rev=257690&r1=257689&r2=257690&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/process_launch/TestProcessLaunch.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/process_launch/TestProcessLaunch.py
 Wed Jan 13 16:32:31 2016
@@ -4,15 +4,12 @@ Test lldb process launch flags.
 
 from __future__ import print_function
 
-import copy
-import os
-import time
 
+
+import os, time
 import lldb
 from lldbsuite.test.lldbtest import *
 
-import six
-
 class ProcessLaunchTestCase(TestBase):
 
 mydir = TestBase.compute_mydir(__file__)
@@ -20,18 +17,9 @@ class ProcessLaunchTestCase(TestBase):
 def setUp(self):
 # Call super's setUp().
 TestBase.setUp(self)
-self.stdout_redirect_file = 'lldb-stdout-redirect.txt'
 # disable "There is a running process, kill it and restart?" prompt
 self.runCmd("settings set auto-confirm true")
-def tearDown(self):
-self.runCmd("settings clear auto-confirm")
-
-try:
-os.unlink(self.stdout_redirect_file)
-except:
-pass
-
-super().tearDown()
+self.addTearDownHook(lambda: self.runCmd("settings clear 
auto-confirm"))
 
 @not_remote_testsuite_ready
 def test_io (self):
@@ -192,9 +180,8 @@ class ProcessLaunchTestCase(TestBase):
 self.fail(err_msg)
 
 def test_environment_with_special_char (self):
-"""Test that environment variables containing '*' and '}' are handled 
correctly by the inferior."""
-source = 'print_env.cpp'
-d = {'CXX_SOURCES' : source}
+"""Test that environment variables containing '*' and '}' are 
communicated correctly to the lldb-server."""
+d = {'CXX_SOURCES' : 'print_env.cpp'}
 self.build(dictionary=d)
 self.setTearDownCleanup(d)
 exe = os.path.join (os.getcwd(), "a.out")
@@ -202,19 +189,19 @@ class ProcessLaunchTestCase(TestBase):
 evil_var = 'INIT*MIDDLE}TAIL'
 
 target = self.dbg.CreateTarget(exe)
-main_source_spec = lldb.SBFileSpec(source)
-breakpoint = target.BreakpointCreateBySourceRegex('// Set breakpoint 
here.', main_source_spec)
-
 process = target.LaunchSimple(None, ['EVIL=' + evil_var], 
self.get_process_working_directory())
-self.assertEqual(process.GetState(), lldb.eStateStopped, 
PROCESS_STOPPED)
+self.assertEqual(process.GetState(), lldb.eStateExited, PROCESS_EXITED)
 
-threads = lldbutil.get_threads_stopped_at_breakpoint(process, 
breakpoint)
-self.assertEqual(len(threads), 1)
-frame = threads[0].GetFrameAtIndex(0)
-sbvalue = frame.EvaluateExpression("evil")
-value = sbvalue.GetSummary().strip('"')
+out = process.GetSTDOUT(len(evil_var))
+self.assertIsNotNone(out, "Encountered an error reading the process's 
output")
 
-self.assertEqual(value, evil_var)
-process.Continue()
-self.assertEqual(process.GetState(), lldb.eStateExited, PROCESS_EXITED)
-pass
\ No newline at end of file
+out = out[:len(evil_var)]
+if out != evil_var:
+self.fail('The environment variable was mis-coded: %s\n' % 
repr(out))
+
+newline = process.GetSTDOUT(1)
+self.assertIsNotNone(newline, "Encountered an error reading the 
process's output")
+
+newline = newline[0]
+if newline != '\r' and newline != '\n':
+self.fail('Garbage at end of environment variable')

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/process_launch/print_env.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/process_launch/print_env.cpp?rev=257690&r1=257689&r2=257690&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/process_launch/print_env.cpp
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/process_launch/print_env.cpp
 Wed Jan 13 16:32:31 2016
@@ -5,6 +5,7 @@
 int main (int argc, char **argv)
 {
   char *evil = getenv("EVIL");
+  puts(evil);
 
-  return 0;  // Set breakpoint here.
+  return 0;
 }


_

Re: [Lldb-commits] [PATCH] D15527: Add ability to override JIT expr compiler options.

[Luke Drummond via lldb-commits]

ldrumm updated this revision to Diff 44794.
ldrumm added a comment.

Responding to Sean Callanan's suggestions in previous differential RE accepting 
an existing set of TargetOptions as the basis to configure a custom set.


http://reviews.llvm.org/D15527

Files:
  include/lldb/Target/LanguageRuntime.h

Index: include/lldb/Target/LanguageRuntime.h
===
--- include/lldb/Target/LanguageRuntime.h
+++ include/lldb/Target/LanguageRuntime.h
@@ -150,7 +150,7 @@
 }
 
 virtual OverrideExprOptions *
-GetOverrideExprOptions()
+GetOverrideExprOptions(const clang::TargetOptions &proto)
 {
 return nullptr;
 }


Index: include/lldb/Target/LanguageRuntime.h
===
--- include/lldb/Target/LanguageRuntime.h
+++ include/lldb/Target/LanguageRuntime.h
@@ -150,7 +150,7 @@
 }
 
 virtual OverrideExprOptions *
-GetOverrideExprOptions()
+GetOverrideExprOptions(const clang::TargetOptions &proto)
 {
 return nullptr;
 }
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r257691 - Include IR/DerivedTypes.h instead of IR/Type.h to match LLVM change r256406.

[Hans Wennborg via lldb-commits]

Author: hans
Date: Wed Jan 13 16:40:24 2016
New Revision: 257691

URL: http://llvm.org/viewvc/llvm-project?rev=257691&view=rev
Log:
Include IR/DerivedTypes.h instead of IR/Type.h to match LLVM change r256406.

This is similar to r256407 and fixes the following warning:

In file included from 
/work/llvm-3.8/llvm.src/tools/lldb/source/Target/ThreadPlanCallFunctionUsingABI.cpp:14:
In file included from 
/work/llvm-3.8/llvm.src/tools/lldb/include/lldb/Target/ThreadPlanCallFunctionUsingABI.h:23:
/work/llvm-3.8/llvm.src/include/llvm/IR/Type.h:350:16: error: inline function 
'llvm::Type::getSequentialElementType' is not defined 
[-Werror,-Wundefined-inline]
  inline Type *getSequentialElementType() const;
   ^
/work/llvm-3.8/llvm.src/include/llvm/IR/Type.h:353:46: note: used here
  Type *getArrayElementType() const { return getSequentialElementType(); }
 ^
1 error generated.

I'm not sure why it's not showing on any bots.

Modified:
lldb/trunk/include/lldb/Target/ThreadPlanCallFunctionUsingABI.h

Modified: lldb/trunk/include/lldb/Target/ThreadPlanCallFunctionUsingABI.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Target/ThreadPlanCallFunctionUsingABI.h?rev=257691&r1=257690&r2=257691&view=diff
==
--- lldb/trunk/include/lldb/Target/ThreadPlanCallFunctionUsingABI.h (original)
+++ lldb/trunk/include/lldb/Target/ThreadPlanCallFunctionUsingABI.h Wed Jan 13 
16:40:24 2016
@@ -20,7 +20,7 @@
 #include "lldb/Target/ThreadPlanCallFunction.h"
 
 #include "llvm/ADT/ArrayRef.h"
-#include "llvm/IR/Type.h"
+#include "llvm/IR/DerivedTypes.h"
 
 namespace lldb_private {
 


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

[Lldb-commits] [lldb] r257692 - Fix -Wformat-pedantic warning

[Hans Wennborg via lldb-commits]

Author: hans
Date: Wed Jan 13 16:40:26 2016
New Revision: 257692

URL: http://llvm.org/viewvc/llvm-project?rev=257692&view=rev
Log:
Fix -Wformat-pedantic warning

/work/llvm-3.8/llvm.src/tools/lldb/source/API/SBProcess.cpp:1003:73:
error: format specifies type 'void *' but the argument has type 
'lldb_private::Event *' [-Werror,-Wformat-pedantic]
log->Printf ("SBProcess::%s (event.sp=%p) => %d", __FUNCTION__, 
event.get(), ret_val);
  ~~
^~~
1 error generated.

Modified:
lldb/trunk/source/API/SBProcess.cpp

Modified: lldb/trunk/source/API/SBProcess.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/API/SBProcess.cpp?rev=257692&r1=257691&r2=257692&view=diff
==
--- lldb/trunk/source/API/SBProcess.cpp (original)
+++ lldb/trunk/source/API/SBProcess.cpp Wed Jan 13 16:40:26 2016
@@ -1000,7 +1000,8 @@ SBProcess::GetRestartedFromEvent (const
 bool ret_val = Process::ProcessEventData::GetRestartedFromEvent 
(event.get());
 
 if (log)
-log->Printf ("SBProcess::%s (event.sp=%p) => %d", __FUNCTION__, 
event.get(), ret_val);
+log->Printf ("SBProcess::%s (event.sp=%p) => %d", __FUNCTION__,
+ static_cast(event.get()), ret_val);
 
 return ret_val;
 }


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

Re: [Lldb-commits] [lldb] r257692 - Fix -Wformat-pedantic warning

[Hans Wennborg via lldb-commits]

On Wed, Jan 13, 2016 at 2:40 PM, Hans Wennborg via lldb-commits
 wrote:
> Author: hans
> Date: Wed Jan 13 16:40:26 2016
> New Revision: 257692
>
> URL: http://llvm.org/viewvc/llvm-project?rev=257692&view=rev
> Log:
> Fix -Wformat-pedantic warning

Merged to 3.8 in r257706.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r257691 - Include IR/DerivedTypes.h instead of IR/Type.h to match LLVM change r256406.

[Hans Wennborg via lldb-commits]

On Wed, Jan 13, 2016 at 2:40 PM, Hans Wennborg via lldb-commits
 wrote:
> Author: hans
> Date: Wed Jan 13 16:40:24 2016
> New Revision: 257691
>
> URL: http://llvm.org/viewvc/llvm-project?rev=257691&view=rev
> Log:
> Include IR/DerivedTypes.h instead of IR/Type.h to match LLVM change r256406.

Merged to 3.8 in r257704.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D15527: Add ability to override JIT expr compiler options.

[Sean Callanan via lldb-commits]

spyffe added a comment.

What I'm getting at here is: OverrideExprOptions just subclasses 
clang::TargetOptions if I'm not mistaken.  What I might suggest is

virtual bool
OverrideExprOptions (clang::TargetOptions &options)
{

  return false; // return true if you actually modified "options"

}

You'd just modify the compiler's target options in place.  That way you only 
touch the state you care about, and nothing gets dynamically allocated (except 
the backing stores for the strings in the TargetOptions...)


http://reviews.llvm.org/D15527



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

[Lldb-commits] [lldb] r257717 - change Xcode test run default to ignore xpass on Xunit output

[Todd Fiala via lldb-commits]

Author: tfiala
Date: Wed Jan 13 17:55:16 2016
New Revision: 257717

URL: http://llvm.org/viewvc/llvm-project?rev=257717&view=rev
Log:
change Xcode test run default to ignore xpass on Xunit output

The Green Dragon LLVM builders are starting to parse xunit output
on LLDB Xcode builders.  By default the XML formatter treats
xpass (unexpected successes) as failures.  The new flag added
ensures we simply ignore those for purposes of xUnit output.
LLDB is not currently XPASS clean.

Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj

Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lldb.xcodeproj/project.pbxproj?rev=257717&r1=257716&r2=257717&view=diff
==
--- lldb/trunk/lldb.xcodeproj/project.pbxproj (original)
+++ lldb/trunk/lldb.xcodeproj/project.pbxproj Wed Jan 13 17:55:16 2016
@@ -5928,7 +5928,7 @@
 /* Begin PBXLegacyTarget section */
2387551E1C24974600CCE8C3 /* lldb-python-test-suite */ = {
isa = PBXLegacyTarget;
-   buildArgumentsString = "-u $(SRCROOT)/test/dotest.py 
--apple-sdk $(PLATFORM_NAME) 
--executable=$(BUILD_DIR)/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)/lldb 
--results-formatter lldbsuite.test.xunit_formatter.XunitFormatter 
--results-file $(BUILD_DIR)/test-results.xml --rerun-all-issues --env 
TERM=vt100";
+   buildArgumentsString = "-u $(SRCROOT)/test/dotest.py 
--apple-sdk $(PLATFORM_NAME) 
--executable=$(BUILD_DIR)/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)/lldb 
--results-formatter lldbsuite.test.xunit_formatter.XunitFormatter 
--results-file $(BUILD_DIR)/test-results.xml --rerun-all-issues --env 
TERM=vt100 -O--xpass=ignore";
buildConfigurationList = 238755241C24974600CCE8C3 /* 
Build configuration list for PBXLegacyTarget "lldb-python-test-suite" */;
buildPhases = (
);
@@ -5937,7 +5937,7 @@
dependencies = (
);
name = "lldb-python-test-suite";
-   passBuildSettingsInEnvironment = 0;
+   passBuildSettingsInEnvironment = 1;
productName = "LLDB Python Test Suite";
};
2687EAC51508110B00DD8C2E /* install-headers */ = {


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

Re: [Lldb-commits] [lldb] r257644 - Fix an issue where scripted commands would not actually print any of their output if an immediate output file was set in the result object via a Python file object

[Ying Chen via lldb-commits]

Hello Enrico,

The new test has been failing on Ubuntu buildbot. But it's passing on some
offline Ubuntu machines, I don't understand what caused the difference.
Could you please help to take a look?

http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/10299

Thanks,
Ying

On Wed, Jan 13, 2016 at 11:32 AM, Enrico Granata via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

>
> On Jan 13, 2016, at 11:26 AM, Zachary Turner  wrote:
>
> Thanks!  btw would having the command write its output to a file instead
> of stdout solve the pexpect problme as well?
>
>
> That’s possible - but I would need to play with it a little bit to
> convince myself that it really is a faithful reproduction of my original
> issue
> It’ll take me a little while to get to it - stay tuned.
>
> On Wed, Jan 13, 2016 at 11:22 AM Enrico Granata 
> wrote:
>
>>
>> On Jan 13, 2016, at 10:34 AM, Zachary Turner  wrote:
>>
>>
>>
>> On Wed, Jan 13, 2016 at 10:25 AM Enrico Granata 
>> wrote:
>>
>>> On Jan 13, 2016, at 10:21 AM, Zachary Turner  wrote:
>>>
>>>
>>> On Wed, Jan 13, 2016 at 10:15 AM Enrico Granata via lldb-commits <
>>> lldb-commits@lists.llvm.org> wrote:
>>>
 +
 +class CommandScriptImmediateOutputTestCase (PExpectTest):

>>> Does the bug that you were trying to fix occur only when using the
>>> command_script.py file from the lldb command line?  If you load it from
>>> within lldb via an LLDB command, does the problem still occur?  If the
>>> problem you are fixing is not specific to the LLDB command line, I would
>>> prefer if you write this not as a pexpect test.
>>>
>>>
>>> I would love to not touch pexpect :-) But in this case, I can’t see a
>>> way around it. I am trying to detect whether some text is “physically”
>>> printed to stdout. And pexpect seems the most obvious straightforward way
>>> to get that to happen. Note that, in this bug, the result object is filled
>>> in correctly even if nothing gets printed, so looking at the result won’t
>>> quite cut it - it really needs to detect output to stdout.
>>>
>> You're calling result.SetImmediateOutputFile(sys.__stdout__).  Wouldn't
>> it work to use a file on the file system here, and then you open that file
>> and look at it after running the commands?  It wouldn't work in remote
>> cases, but it already doesn't work on remote cases anyway (as you point out
>> below)
>>
>>
>>>
>>>
>>>
 +
 +mydir = TestBase.compute_mydir(__file__)
 +
 +def setUp(self):
 +# Call super's setUp().
 +PExpectTest.setUp(self)
 +
 +@skipIfRemote # test not remote-ready llvm.org/pr24813
 +@expectedFlakeyFreeBSD("llvm.org/pr25172 fails rarely on the
 buildbot")
 +@expectedFlakeyLinux("llvm.org/pr25172")

>>> Are these necessary?  The windows one is necessary (but not if you
>>> change this to not being a pexpect test as I've requested above), but why
>>> are the other ones necessary?
>>>
>>>
>>> Do we support remote pexpect? As for FreeBSD and Linux, they might not
>>> be necessary, but I’d rather much remove them (or let the relevant platform
>>> owners) remove them in a separate commit
>>>
>>> No remote pexpect, so the @skipIfRemote probably needs to be there.  But
>> I think everyone should be checking in tests enabled by default in the
>> widest set of environments possible that you aren't completely sure are
>> broken.  It should be up to the platform holders to disable broken tests,
>> not to enable working tests.  Because it's much easier to notice a broken
>> test going in than it is to notice a working test went in disabled (because
>> who's going to think to test it out?).
>>
>>
>> This is a fair point. I’ll enable those platforms in a subsequent commit
>> ASAP
>>
>>
>> Thanks,
>> *- Enrico*
>> 📩 egranata@.com ☎️ 27683
>>
>>
>
> Thanks,
> *- Enrico*
> 📩 egranata@.com ☎️ 27683
>
>
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r257644 - Fix an issue where scripted commands would not actually print any of their output if an immediate output file was set in the result object via a Python file object

[Enrico Granata via lldb-commits]

From the buildbot log it’s quite hard to tell what could be going on

Is there any chance you guys could run the test by hand with the “-t -v” flags 
to the dotest.py driver and attach the output of the run?

That might help figure out where the issue lies

> On Jan 13, 2016, at 5:35 PM, Ying Chen  wrote:
> 
> Hello Enrico,
> 
> The new test has been failing on Ubuntu buildbot. But it's passing on some 
> offline Ubuntu machines, I don't understand what caused the difference.
> Could you please help to take a look?
> 
> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/10299 
> 
> 
> Thanks,
> Ying
> 
> On Wed, Jan 13, 2016 at 11:32 AM, Enrico Granata via lldb-commits 
> mailto:lldb-commits@lists.llvm.org>> wrote:
> 
>> On Jan 13, 2016, at 11:26 AM, Zachary Turner > > wrote:
>> 
>> Thanks!  btw would having the command write its output to a file instead of 
>> stdout solve the pexpect problme as well?
>> 
> 
> That’s possible - but I would need to play with it a little bit to convince 
> myself that it really is a faithful reproduction of my original issue
> It’ll take me a little while to get to it - stay tuned.
> 
>> On Wed, Jan 13, 2016 at 11:22 AM Enrico Granata > > wrote:
>> 
>>> On Jan 13, 2016, at 10:34 AM, Zachary Turner >> > wrote:
>>> 
>>> 
>>> 
>>> On Wed, Jan 13, 2016 at 10:25 AM Enrico Granata >> > wrote:
 On Jan 13, 2016, at 10:21 AM, Zachary Turner >>> > wrote:
 
 
 On Wed, Jan 13, 2016 at 10:15 AM Enrico Granata via lldb-commits 
 mailto:lldb-commits@lists.llvm.org>> wrote:
 +
 +class CommandScriptImmediateOutputTestCase (PExpectTest):
 Does the bug that you were trying to fix occur only when using the 
 command_script.py file from the lldb command line?  If you load it from 
 within lldb via an LLDB command, does the problem still occur?  If the 
 problem you are fixing is not specific to the LLDB command line, I would 
 prefer if you write this not as a pexpect test.
>>> 
>>> I would love to not touch pexpect :-) But in this case, I can’t see a way 
>>> around it. I am trying to detect whether some text is “physically” printed 
>>> to stdout. And pexpect seems the most obvious straightforward way to get 
>>> that to happen. Note that, in this bug, the result object is filled in 
>>> correctly even if nothing gets printed, so looking at the result won’t 
>>> quite cut it - it really needs to detect output to stdout.
>>> You're calling result.SetImmediateOutputFile(sys.__stdout__).  Wouldn't it 
>>> work to use a file on the file system here, and then you open that file and 
>>> look at it after running the commands?  It wouldn't work in remote cases, 
>>> but it already doesn't work on remote cases anyway (as you point out below)
>>>  
>>> 
  
 +
 +mydir = TestBase.compute_mydir(__file__)
 +
 +def setUp(self):
 +# Call super's setUp().
 +PExpectTest.setUp(self)
 +
 +@skipIfRemote # test not remote-ready llvm.org/pr24813 
 
 +@expectedFlakeyFreeBSD("llvm.org/pr25172  
 fails rarely on the buildbot")
 +@expectedFlakeyLinux("llvm.org/pr25172 ")
 Are these necessary?  The windows one is necessary (but not if you change 
 this to not being a pexpect test as I've requested above), but why are the 
 other ones necessary?
>>> 
>>> 
>>> Do we support remote pexpect? As for FreeBSD and Linux, they might not be 
>>> necessary, but I’d rather much remove them (or let the relevant platform 
>>> owners) remove them in a separate commit
>>> 
>>> No remote pexpect, so the @skipIfRemote probably needs to be there.  But I 
>>> think everyone should be checking in tests enabled by default in the widest 
>>> set of environments possible that you aren't completely sure are broken.  
>>> It should be up to the platform holders to disable broken tests, not to 
>>> enable working tests.  Because it's much easier to notice a broken test 
>>> going in than it is to notice a working test went in disabled (because 
>>> who's going to think to test it out?).
>> 
>> 
>> This is a fair point. I’ll enable those platforms in a subsequent commit ASAP
>> 
>> 
>> Thanks,
>> - Enrico
>> 📩 egranata@.com ☎️ 27683
>> 
> 
> 
> 
> Thanks,
> - Enrico
> 📩 egranata@.com ☎️ 27683
> 
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org 
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits 
> 
> 
> 


Thanks,
- Enrico
📩 egranata@.com ☎️ 27683

___
lldb-commits mailing list
lldb-c

Re: [Lldb-commits] [lldb] r257644 - Fix an issue where scripted commands would not actually print any of their output if an immediate output file was set in the result object via a Python file object

[Ying Chen via lldb-commits]

Please see attached log file.

Thanks,
Ying

On Wed, Jan 13, 2016 at 5:39 PM, Enrico Granata  wrote:

> From the buildbot log it’s quite hard to tell what could be going on
>
> Is there any chance you guys could run the test by hand with the “-t -v”
> flags to the dotest.py driver and attach the output of the run?
>
> That might help figure out where the issue lies
>
> On Jan 13, 2016, at 5:35 PM, Ying Chen  wrote:
>
> Hello Enrico,
>
> The new test has been failing on Ubuntu buildbot. But it's passing on some
> offline Ubuntu machines, I don't understand what caused the difference.
> Could you please help to take a look?
>
>
> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/10299
>
> Thanks,
> Ying
>
> On Wed, Jan 13, 2016 at 11:32 AM, Enrico Granata via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
>>
>> On Jan 13, 2016, at 11:26 AM, Zachary Turner  wrote:
>>
>> Thanks!  btw would having the command write its output to a file instead
>> of stdout solve the pexpect problme as well?
>>
>>
>> That’s possible - but I would need to play with it a little bit to
>> convince myself that it really is a faithful reproduction of my original
>> issue
>> It’ll take me a little while to get to it - stay tuned.
>>
>> On Wed, Jan 13, 2016 at 11:22 AM Enrico Granata 
>> wrote:
>>
>>>
>>> On Jan 13, 2016, at 10:34 AM, Zachary Turner  wrote:
>>>
>>>
>>>
>>> On Wed, Jan 13, 2016 at 10:25 AM Enrico Granata 
>>> wrote:
>>>
 On Jan 13, 2016, at 10:21 AM, Zachary Turner 
 wrote:


 On Wed, Jan 13, 2016 at 10:15 AM Enrico Granata via lldb-commits <
 lldb-commits@lists.llvm.org> wrote:

> +
> +class CommandScriptImmediateOutputTestCase (PExpectTest):
>
 Does the bug that you were trying to fix occur only when using the
 command_script.py file from the lldb command line?  If you load it from
 within lldb via an LLDB command, does the problem still occur?  If the
 problem you are fixing is not specific to the LLDB command line, I would
 prefer if you write this not as a pexpect test.


 I would love to not touch pexpect :-) But in this case, I can’t see a
 way around it. I am trying to detect whether some text is “physically”
 printed to stdout. And pexpect seems the most obvious straightforward way
 to get that to happen. Note that, in this bug, the result object is filled
 in correctly even if nothing gets printed, so looking at the result won’t
 quite cut it - it really needs to detect output to stdout.

>>> You're calling result.SetImmediateOutputFile(sys.__stdout__).  Wouldn't
>>> it work to use a file on the file system here, and then you open that file
>>> and look at it after running the commands?  It wouldn't work in remote
>>> cases, but it already doesn't work on remote cases anyway (as you point out
>>> below)
>>>
>>>



> +
> +mydir = TestBase.compute_mydir(__file__)
> +
> +def setUp(self):
> +# Call super's setUp().
> +PExpectTest.setUp(self)
> +
> +@skipIfRemote # test not remote-ready llvm.org/pr24813
> +@expectedFlakeyFreeBSD("llvm.org/pr25172 fails rarely on the
> buildbot")
> +@expectedFlakeyLinux("llvm.org/pr25172")
>
 Are these necessary?  The windows one is necessary (but not if you
 change this to not being a pexpect test as I've requested above), but why
 are the other ones necessary?


 Do we support remote pexpect? As for FreeBSD and Linux, they might not
 be necessary, but I’d rather much remove them (or let the relevant platform
 owners) remove them in a separate commit

 No remote pexpect, so the @skipIfRemote probably needs to be there.
>>> But I think everyone should be checking in tests enabled by default in the
>>> widest set of environments possible that you aren't completely sure are
>>> broken.  It should be up to the platform holders to disable broken tests,
>>> not to enable working tests.  Because it's much easier to notice a broken
>>> test going in than it is to notice a working test went in disabled (because
>>> who's going to think to test it out?).
>>>
>>>
>>> This is a fair point. I’ll enable those platforms in a subsequent commit
>>> ASAP
>>>
>>>
>>> Thanks,
>>> *- Enrico*
>>> 📩 egranata@.com ☎️ 27683
>>>
>>>
>>
>> Thanks,
>> *- Enrico*
>> 📩 egranata@.com ☎️ 27683
>>
>>
>> ___
>> lldb-commits mailing list
>> lldb-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>>
>>
>
>
> Thanks,
> *- Enrico*
> 📩 egranata@.com ☎️ 27683
>
>
lldb version 3.9.0 ( http://llvm.org/svn/llvm-project/lldb/trunk revision 257733 clang revision 257733 llvm revision 257733)

Session logs for test failures/errors/unexpected successes will go into directory 'logs-clang-3.5-i386'
Command invoked: /lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../llvm/tools/lldb/test/dotest