llvm-project/lldb/test/functionalities/target_command/TestTargetCommand.py

199 lines
8.6 KiB
Python
Raw Normal View History

"""
Test some target commands: create, list, select, variable.
"""
import unittest2
import lldb
import sys
from lldbtest import *
class targetCommandTestCase(TestBase):
mydir = os.path.join("functionalities", "target_command")
def setUp(self):
# Call super's setUp().
TestBase.setUp(self)
# Find the line numbers for our breakpoints.
self.line_b = line_number('b.c', '// Set break point at this line.')
self.line_c = line_number('c.c', '// Set break point at this line.')
def test_target_command_with_dwarf(self):
"""Test some target commands: create, list, select."""
da = {'C_SOURCES': 'a.c', 'EXE': 'a.out'}
self.buildDwarf(dictionary=da)
self.addTearDownCleanup(dictionary=da)
db = {'C_SOURCES': 'b.c', 'EXE': 'b.out'}
self.buildDwarf(dictionary=db)
self.addTearDownCleanup(dictionary=db)
dc = {'C_SOURCES': 'c.c', 'EXE': 'c.out'}
self.buildDwarf(dictionary=dc)
self.addTearDownCleanup(dictionary=dc)
self.do_target_command()
# rdar://problem/9763907
# 'target variable' command fails if the target program has been run
@unittest2.expectedFailure
@unittest2.skipUnless(sys.platform.startswith("darwin"), "requires Darwin")
def test_target_variable_command_with_dsym(self):
"""Test 'target variable' command before and after starting the inferior."""
d = {'C_SOURCES': 'globals.c', 'EXE': 'globals'}
self.buildDsym(dictionary=d)
self.addTearDownCleanup(dictionary=d)
self.do_target_variable_command('globals')
Redesign of the interaction between Python and frozen objects: - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
2011-09-07 03:20:51 +08:00
@unittest2.skipUnless(sys.platform.startswith("darwin"), "requires Darwin")
def test_target_variable_command_with_dsym_no_fail(self):
"""Test 'target variable' command before and after starting the inferior."""
d = {'C_SOURCES': 'globals.c', 'EXE': 'globals'}
self.buildDsym(dictionary=d)
self.addTearDownCleanup(dictionary=d)
self.do_target_variable_command_no_fail('globals')
def do_target_command(self):
"""Exercise 'target create', 'target list', 'target select' commands."""
exe_a = os.path.join(os.getcwd(), "a.out")
exe_b = os.path.join(os.getcwd(), "b.out")
exe_c = os.path.join(os.getcwd(), "c.out")
self.runCmd("target list")
output = self.res.GetOutput()
if output.startswith("No targets"):
# We start from index 0.
base = 0
else:
# Find the largest index of the existing list.
import re
pattern = re.compile("target #(\d+):")
for line in reversed(output.split(os.linesep)):
match = pattern.search(line)
if match:
# We will start from (index + 1) ....
base = int(match.group(1), 10) + 1
#print "base is:", base
break;
self.runCmd("target create " + exe_a, CURRENT_EXECUTABLE_SET)
self.runCmd("run", RUN_SUCCEEDED)
self.runCmd("target create " + exe_b, CURRENT_EXECUTABLE_SET)
self.runCmd("breakpoint set -f %s -l %d" % ('b.c', self.line_b),
BREAKPOINT_CREATED)
self.runCmd("run", RUN_SUCCEEDED)
self.runCmd("target create " + exe_c, CURRENT_EXECUTABLE_SET)
self.runCmd("breakpoint set -f %s -l %d" % ('c.c', self.line_c),
BREAKPOINT_CREATED)
self.runCmd("run", RUN_SUCCEEDED)
self.runCmd("target list")
self.runCmd("target select %d" % base)
self.runCmd("thread backtrace")
self.runCmd("target select %d" % (base + 2))
self.expect("thread backtrace", STOPPED_DUE_TO_BREAKPOINT,
substrs = ['c.c:%d' % self.line_c,
'stop reason = breakpoint'])
self.runCmd("target select %d" % (base + 1))
self.expect("thread backtrace", STOPPED_DUE_TO_BREAKPOINT,
substrs = ['b.c:%d' % self.line_b,
'stop reason = breakpoint'])
self.runCmd("target list")
def do_target_variable_command(self, exe_name):
"""Exercise 'target variable' command before and after starting the inferior."""
self.runCmd("file " + exe_name, CURRENT_EXECUTABLE_SET)
self.expect("target variable my_global_char", VARIABLES_DISPLAYED_CORRECTLY,
substrs = ["my_global_char", "'X'"])
self.expect("target variable my_global_str", VARIABLES_DISPLAYED_CORRECTLY,
substrs = ['my_global_str', '"abc"'])
self.expect("target variable my_static_int", VARIABLES_DISPLAYED_CORRECTLY,
substrs = ['my_static_int', '228'])
Redesign of the interaction between Python and frozen objects: - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
2011-09-07 03:20:51 +08:00
self.expect("target variable my_global_str_ptr", matching=False,
substrs = ['"abc"'])
self.expect("target variable *my_global_str_ptr", matching=True,
substrs = ['"abc"'])
self.expect("target variable *my_global_str", VARIABLES_DISPLAYED_CORRECTLY,
substrs = ['a'])
self.runCmd("b main")
self.runCmd("run")
Redesign of the interaction between Python and frozen objects: - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
2011-09-07 03:20:51 +08:00
self.expect("target variable my_global_str", VARIABLES_DISPLAYED_CORRECTLY,
substrs = ['my_global_str', '"abc"'])
self.expect("target variable my_static_int", VARIABLES_DISPLAYED_CORRECTLY,
substrs = ['my_static_int', '228'])
self.expect("target variable my_global_str_ptr", matching=False,
substrs = ['"abc"'])
self.expect("target variable *my_global_str_ptr", matching=True,
substrs = ['"abc"'])
self.expect("target variable *my_global_str", VARIABLES_DISPLAYED_CORRECTLY,
substrs = ['a'])
self.expect("target variable my_global_char", VARIABLES_DISPLAYED_CORRECTLY,
substrs = ["my_global_char", "'X'"])
self.runCmd("c")
# rdar://problem/9763907
# 'target variable' command fails if the target program has been run
Redesign of the interaction between Python and frozen objects: - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
2011-09-07 03:20:51 +08:00
self.expect("target variable my_global_str", VARIABLES_DISPLAYED_CORRECTLY,
substrs = ['my_global_str', '"abc"'])
self.expect("target variable my_static_int", VARIABLES_DISPLAYED_CORRECTLY,
substrs = ['my_static_int', '228'])
self.expect("target variable my_global_str_ptr", matching=False,
substrs = ['"abc"'])
self.expect("target variable *my_global_str_ptr", matching=True,
substrs = ['"abc"'])
self.expect("target variable *my_global_str", VARIABLES_DISPLAYED_CORRECTLY,
substrs = ['a'])
self.expect("target variable my_global_char", VARIABLES_DISPLAYED_CORRECTLY,
substrs = ["my_global_char", "'X'"])
def do_target_variable_command_no_fail(self, exe_name):
"""Exercise 'target variable' command before and after starting the inferior."""
self.runCmd("file " + exe_name, CURRENT_EXECUTABLE_SET)
self.expect("target variable my_global_char", VARIABLES_DISPLAYED_CORRECTLY,
substrs = ["my_global_char", "'X'"])
self.expect("target variable my_global_str", VARIABLES_DISPLAYED_CORRECTLY,
substrs = ['my_global_str', '"abc"'])
self.expect("target variable my_static_int", VARIABLES_DISPLAYED_CORRECTLY,
substrs = ['my_static_int', '228'])
Redesign of the interaction between Python and frozen objects: - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
2011-09-07 03:20:51 +08:00
self.expect("target variable my_global_str_ptr", matching=False,
substrs = ['"abc"'])
self.expect("target variable *my_global_str_ptr", matching=True,
substrs = ['"abc"'])
self.expect("target variable *my_global_str", VARIABLES_DISPLAYED_CORRECTLY,
substrs = ['a'])
self.runCmd("b main")
self.runCmd("run")
self.expect("target variable my_global_str", VARIABLES_DISPLAYED_CORRECTLY,
substrs = ['my_global_str', '"abc"'])
self.expect("target variable my_static_int", VARIABLES_DISPLAYED_CORRECTLY,
substrs = ['my_static_int', '228'])
self.expect("target variable my_global_str_ptr", matching=False,
substrs = ['"abc"'])
self.expect("target variable *my_global_str_ptr", matching=True,
substrs = ['"abc"'])
self.expect("target variable *my_global_str", VARIABLES_DISPLAYED_CORRECTLY,
substrs = ['a'])
self.expect("target variable my_global_char", VARIABLES_DISPLAYED_CORRECTLY,
substrs = ["my_global_char", "'X'"])
if __name__ == '__main__':
import atexit
lldb.SBDebugger.Initialize()
atexit.register(lambda: lldb.SBDebugger.Terminate())
unittest2.main()