History log of /external/lldb/test/expression_command/issue_11588/Test11588.py
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
00ebf2a9e5042fbf514c99a013e37de28a871fab 02-Apr-2013 Greg Clayton <gclayton@apple.com> Fix test case to not run to main and "next" 5 times. Use a breakpoint.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178552 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/expression_command/issue_11588/Test11588.py
3a91e146f4e40ce9b44af3619551f6b6d9bb3b7f 09-Jan-2013 Enrico Granata <egranata@apple.com> <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.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@171993 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/expression_command/issue_11588/Test11588.py
691e74c60a50ef5f77b12e6934247c747ed2b232 07-Dec-2012 Andrew Kaylor <andrew.kaylor@intel.com> 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.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@169615 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/expression_command/issue_11588/Test11588.py
22cf41b1ac6d408f8dd15e27445c0221dcd33439 11-May-2012 Filipe Cabecinhas <me@filcab.net> Make issue_11588/Test11588 work with a recent swig that converts ints to PyLongObjects


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@156637 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/expression_command/issue_11588/Test11588.py
20c13076457503ab3bf32b9da9c24c6d051d4997 25-Apr-2012 Sean Callanan <scallanan@apple.com> Made it safe to re-import a Python module, allowing
the same test to be run multiple times in the same
session.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@155511 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/expression_command/issue_11588/Test11588.py
ac4583a82bfe39477450c7230f200dd5297e2f87 19-Apr-2012 Johnny Chen <johnny.chen@apple.com> 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


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@155144 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/expression_command/issue_11588/Test11588.py
67130e42592e68c3055e7ab5b7a368d89a06f05e 19-Apr-2012 Johnny Chen <johnny.chen@apple.com> Add expected failure decorators for test cases which are failing for i386 architecture.
Plus fix some test cases to skip/succeed for i386.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@155087 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/expression_command/issue_11588/Test11588.py
c61349681fa2923bd30ad16afce450a0da6108cf 06-Jan-2012 Johnny Chen <johnny.chen@apple.com> 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.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@147637 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/expression_command/issue_11588/Test11588.py
dfafa141aa9d0dd0596bf08b3f941be8c308316d 17-Dec-2011 Johnny Chen <johnny.chen@apple.com> 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.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@146768 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/expression_command/issue_11588/Test11588.py