This patch adds the option -l/--language to the expression command, for use when setting the language options or choosing an alternate FE. If not specified, the target.language setting is used. It is the expression counterpart of http://reviews.llvm.org/D11119 which added the --language option to breakpoint set command.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
One thing you might want to fix is to use:
self.dbg.HandleCommand("...")
This avoids the need for the command to succeed.
runCmd can take a named argument "check = False" that will stop the mandatory checking of the success of the command.
test/expression_command/options/TestExprOptions.py | ||
---|---|---|
37–42 | Actually don't make tests that use runCmd for creating targets use the following code: # Set debugger into synchronous mode self.dbg.SetAsync(False) # Create a target by the debugger. exe = os.path.join(os.getcwd(), "a.out") target = self.dbg.CreateTarget(exe) self.assertTrue(target, VALID_TARGET) # Set breakpoints inside and outside methods that take pointers to the containing struct. lldbutil.run_break_set_by_file_and_line (self, self.source, line, num_expected_locations=1, loc_exact=True) # Register our shared libraries for remote targets so they get automatically uploaded arguments = None environment = None # Now launch the process, and do not stop at entry point. process = target.LaunchSimple (arguments, environment, self.get_process_working_directory()) self.assertTrue(process, PROCESS_IS_VALID) |
See inlined comments.
test/expression_command/options/TestExprOptions.py | ||
---|---|---|
47–56 | use self.runCmd(check=False,...) instead of self.expect(...). You should actually use the "lldb.SB*" API if possible unless you are explicitly trying to test textual output from commands. Please don't use self.expect() or self.runCmd() if you can use "lldb.SB*" API calls. |
I am trying to check textual output from commands. expect() doesn't take a check=False option, and runCmd() doesn't check for output afaik. It would be possible to pipe all the output and check that way, but what a major pain.
How do you suggest I get this to fly?:
self.expect("expression blabla", startstr = "error")
I want to test that lldb returns error without FAILing
Ah! expect takes a 'error' argument :) This works:
self.expect("expression blabla", error=True, startstr = "error")
To evaluate an expression use the SB API:
threads = lldbutil.get_threads_stopped_at_breakpoint (process, breakpoint) self.assertTrue(len(threads) == 1) thread = threads[0] frame = thread.GetFrameAtIndex(0) options = lldb.SBExpressionOptions() value = frame.EvaluateExpression ("expression blabla", options) self.assertTrue (value.GetError().Fail())
There are many tests that evaluate expressions using the SB API:
expression_command/call-restarts/TestCallThatRestarts.py expression_command/call-throws/TestCallThatThrows.py expression_command/char/TestExprsChar.py expression_command/formatters/TestFormatters.py expression_command/test/TestExprs.py expression_command/timeout/TestCallWithTimeout.py functionalities/asan/TestMemoryHistory.py functionalities/expr-doesnt-deadlock/TestExprDoesntBlock.py functionalities/inline-stepping/TestInlineStepping.py functionalities/watchpoint/watchpoint_commands/command/TestWatchpointCommandPython.py lang/c/stepping/TestStepAndBreakpoints.py lang/cpp/dynamic-value/TestDynamicValue.py lang/objc/blocks/TestObjCIvarsInBlocks.py lang/objc/objc-checker/TestObjCCheckers.py lang/objc/objc-class-method/TestObjCClassMethod.py lang/objc/objc-dynamic-value/TestObjCDynamicValue.py lang/objc/objc-ivar-stripped/TestObjCIvarStripped.py lang/objc/objc-property/TestObjCProperty.py lang/objc/objc-static-method/TestObjCStaticMethod.py lang/objc/objc-static-method-stripped/TestObjCStaticMethodStripped.py lang/objc/objc-struct-argument/TestObjCStructArgument.py lang/objc/objc-struct-return/TestObjCStructReturn.py lang/objc/objc-super/TestObjCSuper.py lang/swift/different_clang_flags/TestSwiftDifferentClangFlags.py lang/swift/expression/access_control/TestExpressionAccessControl.py lang/swift/expression/classes/TestExpressionInMethods.py lang/swift/expression/errors/TestExpressionErrors.py lang/swift/expression/generic/TestGenericExpressions.py lang/swift/expression/scopes/TestExpressionScopes.py lang/swift/expression/simple/TestSimpleExpressions.py lang/swift/expression/static/TestGenericExpressions.py lang/swift/file_private/TestFilePrivate.py lang/swift/struct_change_rerun/TestSwiftStructChangeRerun.py lang/swift/swiftieformatting/TestSwiftieFormatting.py lang/swift/variables/globals/TestSwiftGlobals.py lang/swift/variables/inout/TestInOutVariables.py lldbinline.py python_api/default-constructor/sb_frame.py python_api/frame/TestFrames.py python_api/value/TestValueAPI.py
Please use SB API calls for expression evaluation instead of self.expect calls.
test/expression_command/options/TestExprOptions.py | ||
---|---|---|
57–87 | Please use SB API calls for expression evaluation instead of self.expect calls. |
This all looks all right to me, except that we should print errors if C or Objective-C is requested, because we can only run in C++ or Objective-C++ mode.
We should be careful to switch away from ObjC++ only on request, and not based on the current compilation unit's language, but that's a different patch.
Actually don't make tests that use runCmd for creating targets use the following code: