maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lldb/test/expression_command/issue_11588/Test11588.py

77 lines
2.7 KiB
Python
Raw Normal View History

http://llvm.org/bugs/show_bug.cgi?id=11588 valobj.AddressOf() returns None when an address is expected in a SyntheticChildrenProvider Patch from Enrico Granata: The problem was that the frozen object created by the expression parser was a copy of the contents of the StgClosure, rather than a pointer to it. Thus, the expression parser was correctly computing the result of the arithmetic&cast operation along with its address, but only saving it in the live object. This meant that the frozen copy acted as an address-less variable, hence the problem. The fix attached to this email lets the expression parser store the "live address" in the frozen copy of the address when the object is built without a valid address of its own. Doing so, along with delegating ValueObjectConstResult to calculate its own address when necessary, solves the issue. I have also added a new test case to check for regressions in this area, and checked that existing test cases pass correctly. llvm-svn: 146768
2011-12-17 07:04:52 +08:00
"""
Test the solution to issue 11581.
valobj.AddressOf() returns None when an address is
expected in a SyntheticChildrenProvider
"""
import os, time
import unittest2
import lldb
from lldbtest import *
class Issue11581TestCase(TestBase):
mydir = os.path.join("expression_command", "issue_11588")
def test_11581_commands(self):
# This is the function to remove the custom commands in order to have a
# clean slate for the next test case.
def cleanup():
self.runCmd('type synthetic clear', check=False)
# Execute the cleanup function during test case tear down.
self.addTearDownHook(cleanup)
"""valobj.AddressOf() should return correct values."""
self.buildDefault()
self.runCmd("file a.out", CURRENT_EXECUTABLE_SET)
self.runCmd("breakpoint set --name main")
self.runCmd("run", RUN_SUCCEEDED)
self.runCmd("next", RUN_SUCCEEDED)
self.runCmd("next", RUN_SUCCEEDED)
self.runCmd("next", RUN_SUCCEEDED)
self.runCmd("next", RUN_SUCCEEDED)
self.runCmd("next", RUN_SUCCEEDED)
Made it safe to re-import a Python module, allowing the same test to be run multiple times in the same session. llvm-svn: 155511
2012-04-25 08:21:42 +08:00
self.runCmd("command script import --allow-reload s11588.py")
http://llvm.org/bugs/show_bug.cgi?id=11588 valobj.AddressOf() returns None when an address is expected in a SyntheticChildrenProvider Patch from Enrico Granata: The problem was that the frozen object created by the expression parser was a copy of the contents of the StgClosure, rather than a pointer to it. Thus, the expression parser was correctly computing the result of the arithmetic&cast operation along with its address, but only saving it in the live object. This meant that the frozen copy acted as an address-less variable, hence the problem. The fix attached to this email lets the expression parser store the "live address" in the frozen copy of the address when the object is built without a valid address of its own. Doing so, along with delegating ValueObjectConstResult to calculate its own address when necessary, solves the issue. I have also added a new test case to check for regressions in this area, and checked that existing test cases pass correctly. llvm-svn: 146768
2011-12-17 07:04:52 +08:00
self.runCmd("type synthetic add --python-class s11588.Issue11581SyntheticProvider StgClosure")
<rdar://problem/12028723> Adding useful formatting options to the expression (expr) command. As a side effect of this change, the -d option now supports the same three-values enumeration that frame variables uses (run, don't run, none) instead of a boolean like it did previously These options do not apply to print, p or po because these are aliased to not take any options. In order to use them, use expression or expr. llvm-svn: 171993
2013-01-10 04:12:53 +08:00
self.expect("expr --show-types -- *((StgClosure*)(r14-1))",
http://llvm.org/bugs/show_bug.cgi?id=11588 valobj.AddressOf() returns None when an address is expected in a SyntheticChildrenProvider Patch from Enrico Granata: The problem was that the frozen object created by the expression parser was a copy of the contents of the StgClosure, rather than a pointer to it. Thus, the expression parser was correctly computing the result of the arithmetic&cast operation along with its address, but only saving it in the live object. This meant that the frozen copy acted as an address-less variable, hence the problem. The fix attached to this email lets the expression parser store the "live address" in the frozen copy of the address when the object is built without a valid address of its own. Doing so, along with delegating ValueObjectConstResult to calculate its own address when necessary, solves the issue. I have also added a new test case to check for regressions in this area, and checked that existing test cases pass correctly. llvm-svn: 146768
2011-12-17 07:04:52 +08:00
substrs = ["(StgClosure) $",
http://llvm.org/bugs/show_bug.cgi?id=11618 lldb::SBValue::AddressOf does not work on dereferenced registers in synthetic children provider Patch submitted by Enrico Granata. llvm-svn: 147637
2012-01-06 08:35:38 +08:00
"(StgClosure *) &$","0x",
Not a test failure for i386; instead, the test case should be modified to not over-expect type fields for the synthetic childs. rdar://problem/11277013 llvm-svn: 155144
2012-04-20 02:36:11 +08:00
"addr = ",
"load_address = "])
http://llvm.org/bugs/show_bug.cgi?id=11588 valobj.AddressOf() returns None when an address is expected in a SyntheticChildrenProvider Patch from Enrico Granata: The problem was that the frozen object created by the expression parser was a copy of the contents of the StgClosure, rather than a pointer to it. Thus, the expression parser was correctly computing the result of the arithmetic&cast operation along with its address, but only saving it in the live object. This meant that the frozen copy acted as an address-less variable, hence the problem. The fix attached to this email lets the expression parser store the "live address" in the frozen copy of the address when the object is built without a valid address of its own. Doing so, along with delegating ValueObjectConstResult to calculate its own address when necessary, solves the issue. I have also added a new test case to check for regressions in this area, and checked that existing test cases pass correctly. llvm-svn: 146768
2011-12-17 07:04:52 +08:00
http://llvm.org/bugs/show_bug.cgi?id=11618 lldb::SBValue::AddressOf does not work on dereferenced registers in synthetic children provider Patch submitted by Enrico Granata. llvm-svn: 147637
2012-01-06 08:35:38 +08:00
target = lldb.debugger.GetSelectedTarget()
process = target.GetProcess()
# register r14 does not exist on 32-bit architectures, it is an x86_64 extension
# let's skip this part of the test if we are in 32-bit mode
if process.GetAddressByteSize() == 8:
frame = process.GetSelectedThread().GetSelectedFrame()
pointer = frame.FindVariable("r14")
addr = pointer.GetValueAsUnsigned(0)
self.assertTrue(addr != 0, "could not read pointer to StgClosure")
addr = addr - 1
self.runCmd("register write r14 %d" % addr)
self.expect("register read r14",
Make issue_11588/Test11588 work with a recent swig that converts ints to PyLongObjects llvm-svn: 156637
2012-05-12 04:37:34 +08:00
substrs = ["0x",hex(addr)[2:].rstrip("L")]) # Remove trailing 'L' if it exists
<rdar://problem/12028723> Adding useful formatting options to the expression (expr) command. As a side effect of this change, the -d option now supports the same three-values enumeration that frame variables uses (run, don't run, none) instead of a boolean like it did previously These options do not apply to print, p or po because these are aliased to not take any options. In order to use them, use expression or expr. llvm-svn: 171993
2013-01-10 04:12:53 +08:00
self.expect("expr --show-types -- *(StgClosure*)$r14",
http://llvm.org/bugs/show_bug.cgi?id=11618 lldb::SBValue::AddressOf does not work on dereferenced registers in synthetic children provider Patch submitted by Enrico Granata. llvm-svn: 147637
2012-01-06 08:35:38 +08:00
substrs = ["(StgClosure) $",
"(StgClosure *) &$","0x",
Fix Test11588.py on Linux. The test was failing because the synthetic type fields were resolving to int instead of long. A similar change was made in r155144 to eliminate the type specification for an earlier check in this test, so it seemed appropriate here too. llvm-svn: 169615
2012-12-08 01:45:05 +08:00
"addr = ",
"load_address = ",
Make issue_11588/Test11588 work with a recent swig that converts ints to PyLongObjects llvm-svn: 156637
2012-05-12 04:37:34 +08:00
hex(addr)[2:].rstrip("L"),
http://llvm.org/bugs/show_bug.cgi?id=11618 lldb::SBValue::AddressOf does not work on dereferenced registers in synthetic children provider Patch submitted by Enrico Granata. llvm-svn: 147637
2012-01-06 08:35:38 +08:00
str(addr)])
http://llvm.org/bugs/show_bug.cgi?id=11588 valobj.AddressOf() returns None when an address is expected in a SyntheticChildrenProvider Patch from Enrico Granata: The problem was that the frozen object created by the expression parser was a copy of the contents of the StgClosure, rather than a pointer to it. Thus, the expression parser was correctly computing the result of the arithmetic&cast operation along with its address, but only saving it in the live object. This meant that the frozen copy acted as an address-less variable, hence the problem. The fix attached to this email lets the expression parser store the "live address" in the frozen copy of the address when the object is built without a valid address of its own. Doing so, along with delegating ValueObjectConstResult to calculate its own address when necessary, solves the issue. I have also added a new test case to check for regressions in this area, and checked that existing test cases pass correctly. llvm-svn: 146768
2011-12-17 07:04:52 +08:00
if __name__ == '__main__':
import atexit
lldb.SBDebugger.Initialize()
atexit.register(lambda: lldb.SBDebugger.Terminate())
unittest2.main()