[lldb-dev] [Bug 26139] New: CommandScriptImmediateOutputTestCase fails on Linux
https://llvm.org/bugs/show_bug.cgi?id=26139
Bug ID: 26139
Summary: CommandScriptImmediateOutputTestCase fails on Linux
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: tbergham...@google.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified
The test fails on Linux with all tested architecture and compiler with the
following error:
==
ERROR: test_command_script_immediate_output_dwarf
(TestCommandScriptImmediateOutput.CommandScriptImmediateOutputTestCase)
Test that LLDB correctly allows scripted commands to set an immediate output
file.
--
Traceback (most recent call last):
File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 2249, in dwarf_test_method
return attrvalue(self)
File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 836, in wrapper
func(*args, **kwargs)
File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 769, in wrapper
func(*args, **kwargs)
File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 769, in wrapper
func(*args, **kwargs)
File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 608, in wrapper
func(*args, **kwargs)
File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/command_script_immediate_output/TestCommandScriptImmediateOutput.py",
line 35, in test_command_script_immediate_output
self.sendline('mycommand', patterns='this is a test string, just a test
string')
File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbpexpect.py",
line 57, in sendline
return self.sendimpl(self.child.sendline, command, patterns, timeout,
exact)
File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbpexpect.py",
line 51, in sendimpl
return self.expect(patterns=patterns, timeout=timeout, exact=exact)
File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbpexpect.py",
line 40, in expect
return self.child.expect(patterns, timeout=timeout)
File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/third_party/Python/module/pexpect-2.4/pexpect.py",
line 1316, in expect
return self.expect_list(compiled_pattern_list, timeout, searchwindowsize)
File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/third_party/Python/module/pexpect-2.4/pexpect.py",
line 1330, in expect_list
return self.expect_loop(searcher_re(pattern_list), timeout,
searchwindowsize)
File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/third_party/Python/module/pexpect-2.4/pexpect.py",
line 1414, in expect_loop
raise TIMEOUT (str(e) + '\n' + str(self))
--
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLDB build at windows
> > VS 2013 support is going to be deprecated soon. At that point it could break any time, because nobody is going to be making an effort to keep it > > working. > How is this going to play with Python scripting on Windows? Given that LLDB only supports Python 2.7 bindings, and that Python 2.7 extensions can be built only with VS2008, isn't that going to be a problem? (When LLDB for Windows is officially declared "ready", that is. For now, one can rebuild Python with VS2015.) Vadim ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLDB build at windows
When we move to VS 2015 (which will be soon, btw) we will require Python 3.5+ on Windows. This already works for the most part, you can even try it out today. I've spent the better part of the past 6 months making LLDB's python bindings work with Python 3. The best part is that you don't need to custom build Python 3.5, you can just use the installer from Python.org (make sure you choose to install debug binaries too). So in summary: * VS 2013 -> requires Python custom built version of Python 2.7 * VS 2015 -> requires any version of Python >= 3.5, doesn't have to be custom built. On Thu, Jan 14, 2016 at 10:20 AM Vadim Chugunov via lldb-dev < lldb-dev@lists.llvm.org> wrote: > VS 2013 support is going to be deprecated soon. At that point it could > > break any time, because nobody is going to be making an effort to keep it >> > working. >> > How is this going to play with Python scripting on Windows? Given that LLDB > only supports Python 2.7 bindings, > and that Python 2.7 extensions can be built only with VS2008, isn't that > going to be a problem? > (When LLDB for Windows is officially declared "ready", that is. For now, one > can rebuild Python with VS2015.) > > Vadim > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Patch to fix REPL for ARMv7 & ARMv6 on linux
Hi again, everyone I’d like to ping on this patch now that the 3.8 branch is fairly new, and merging it over is fairly straight-forward. Thanks in advance for your comments! - Will > There is a small change that enables correct calculation of arm sub > architectures while using the REPL on arm-linux. As you may of may or may > not know, linux appends ‘l’ to arm architecture versions to denote little > endian. This sometimes interferes with the determination of the architecture > in the triple. I experimented with adding sub architecture entries for these > within lldb, but I discovered a simpler (and less invasive) method. Because > LLVM already knows how to handle some of these cases (I have a patch > submitted for review that enables v6l; v7l already works), I am relying on > llvm to clean it up. The gist of it is that the llvm constructor (when given > a triple string) retains the provided string unless an accessor mutates it. > Meanwhile, the accessors for the components go through the aliasing and > parsing logic. This code detects whether the sub-architecture that armv6l or > armv7l aliases to is detected, and re-sets the architecture in the triple. > This overwrites the architecture that comes from linux, thus sanitizing it. > > Some kind of solution is required for the REPL to work on arm-linux. Without > it, the REPL crashes. lldb.diff Description: Binary data ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] lldb tests and tear down hooks
So this is biting us again, for unrelated reasons. I thought of a potentially interesting solution. Right now each test class has a setUp and tearDown method. This method is called before and after EVERY test method in the class. So you can't put anything in these methods unless it's common to all test methods. If one particular test method creates a file on the filesystem and wants to clean up that file, you can't use setUp / tearDown because then every test method will be creating / cleaning up files that they don't need. So what if tests could be *either* a method *or* a nested class. If it's a nested class, it could provide setUp, tearDown, and run methods. These setup and teardown methods can do whatever they want specific to the individual test, and it also provides the exception safe way to clean up. For example, instead of this: def test_method(self): self.addTearDownHook(/* do cleanup here */) # run test You could have this: def TestClass(TestMethodBase): def tearDown(self): /* do cleanup here */ TestMethodBase.tearDown(self) def run(self): # run test It's a little bit more code, but a lot more flexible. And we still support the old method of using test methods too, so you only use this when necessary. Thoughts? On Thu, Oct 22, 2015 at 11:38 AM Todd Fiala wrote: > (And side note: if you're pushing a "lambda: self.foo()" with no > arguments, the lambda is unneeded and you can just push "self.foo" --- that > cleanup hook pushed on most tests at the end of the file is a perfect > example of an unneeded level of lambda indirection). > > On Wed, Oct 21, 2015 at 12:04 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> Well you can see them getting added via self.addTearDownHook(), so that >> means they're called through an instance. Specifically, it happens in >> Base.tearDown(self), so it's basically identical (in concept) to if the >> relevant handlers were called in the implementation of MyTest.tearDown(), >> but different in order. >> >> I agree that it's useful in principle to be able to do what you suggest >> in your example, but there's just no way to guarantee the right ordering if >> you let the base class run the handlers. If there actually *were* a >> tearDown() function in your example, to be correct it would need to look >> like this: >> >> class MyTest(TestBase): >> def tearDown(self): >> # run the teardown hooks >> # Do the inverse of setUp() >> super.tearDown() >> >> def test_1(self): >> self.addTearDownHook(lambda: self.foo()) >> raise ValueError >> def test_2(self): >> self.addTearDownHook(lambda: self.bar()) >> raise ValueError >> >> One possible solution is to shift burden of maintaining the hooks list to >> the individual test case. E.g. >> >> class MyTest(TestBase): >> self.hooks = [] >> def tearDown(self): >> self.runTearDownHooks(self.hooks) # This could be implemented >> in TestBase, since now we can call it with our list at the right time. >> # Do the inverse of setUp() >> super.tearDown() >> >> def test_1(self): >> self.hooks.append(lambda: self.foo()) >> raise ValueError >> def test_2(self): >> self.hooks.append(lambda: self.bar()) >> raise ValueError >> >> Almost no extra code to write, and should be bulletproof. >> >> On Wed, Oct 21, 2015 at 11:41 AM Greg Clayton wrote: >> >>> I think it was mostly done to provide an exception safe way to cleanup >>> stuff without having to override TestBase.tearDown(). I am guessing this >>> cleanup happens on TestCase.tearDown() and not after the current test case >>> right? >>> >>> I could see it being used to cleanup after a single test case in case >>> you have: >>> >>> class MyTest(TestBase): >>> def test_1(self): >>> self.addTearDownHook(lambda: self.foo()) >>> raise ValueError >>> def test_2(self): >>> self.addTearDownHook(lambda: self.bar()) >>> raise ValueError >>> >>> >>> Are these tearDowns happening per test function, or during class >>> setup/teardown? >>> >>> > On Oct 21, 2015, at 9:33 AM, Zachary Turner via lldb-dev < >>> lldb-dev@lists.llvm.org> wrote: >>> > >>> > Yea, that's what I think too. I think this mechanism was probably >>> invented to just to save some code and promote reusability, but in practice >>> leads to these kinds of problems. >>> > >>> > On Wed, Oct 21, 2015 at 2:07 AM Pavel Labath >>> wrote: >>> > I think we can remove these, provided there is a way to mimic the >>> > functionality they are used for now, which I think shouldn't be hard. >>> > Anything which was set up in the setUp() method should be undone in >>> > tearDown(). Anything which was set up in the test method, can be >>> > undone using a try-finally block. Is there a use case not covered by >>> > this? >>> > >>> > pl >>> > >>> > On 21 October 2015 at 04:47, Zachary Turner via lldb
[lldb-dev] Get source-map from python API?
Hi, We are building an IDE debugger on top of lldb python API. In order to get the source remapping work(the source path embedded in the symbol may be different from the real source path), user needs to use "settings set target.source-map" command to remap the source. I would like users to do similar thing from our IDE debugger. However, I could not find a python API to specify the source remapping, and more important a way to access the remapping functionality. The SBSourceManager class only exposes a single DisplaySourceLinesWithLineNumbers() method which displays the source in console output. Ideally it should expose an API in SBSourceManager for us to provide the old FileSpec and get back a new remapped FileSpec. Is this not exposed in Python API? Do I need to re-do the remapping logic in our IDE UI code? How is other IDE handling the source remapping? Thanks Jeffrey ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Get source-map from python API?
There is currently no API to access the settings. You have to cons up commands and use SBCommandInterpreter::HandleCommand to execute them. This is one of the remaining holes in the SB API. Jim > On Jan 14, 2016, at 2:41 PM, Jeffrey Tan via lldb-dev > wrote: > > Hi, > > We are building an IDE debugger on top of lldb python API. In order to get > the source remapping work(the source path embedded in the symbol may be > different from the real source path), user needs to use "settings set > target.source-map" command to remap the source. > > I would like users to do similar thing from our IDE debugger. However, I > could not find a python API to specify the source remapping, and more > important a way to access the remapping functionality. The SBSourceManager > class only exposes a single DisplaySourceLinesWithLineNumbers() method which > displays the source in console output. Ideally it should expose an API in > SBSourceManager for us to provide the old FileSpec and get back a new > remapped FileSpec. > > Is this not exposed in Python API? Do I need to re-do the remapping logic in > our IDE UI code? How is other IDE handling the source remapping? > > Thanks > Jeffrey > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
