llvm-project/lldb/packages/Python/lldbsuite/test/source-manager/TestSourceManager.py

257 lines
9.8 KiB
Python
Raw Normal View History

"""
Test lldb core component: SourceManager.
Test cases:
o test_display_source_python:
Test display of source using the SBSourceManager API.
o test_modify_source_file_while_debugging:
Test the caching mechanism of the source manager.
"""
from __future__ import print_function
add stop column highlighting support This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
2016-09-22 04:13:14 +08:00
import re
import lldb
from lldbsuite.test.decorators import *
from lldbsuite.test.lldbtest import *
from lldbsuite.test import lldbutil
add stop column highlighting support This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
2016-09-22 04:13:14 +08:00
def ansi_underline_surround_regex(inner_regex_text):
# return re.compile(r"\[4m%s\[0m" % inner_regex_text)
return "4.+\033\\[4m%s\033\\[0m" % inner_regex_text
class SourceManagerTestCase(TestBase):
mydir = TestBase.compute_mydir(__file__)
add stop column highlighting support This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
2016-09-22 04:13:14 +08:00
SOURCE_FILE = 'main.c'
NO_DEBUG_INFO_TESTCASE = True
def setUp(self):
# Call super's setUp().
TestBase.setUp(self)
# Find the line number to break inside main().
add stop column highlighting support This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
2016-09-22 04:13:14 +08:00
self.line = line_number(self.SOURCE_FILE, '// Set break point at this line.')
def get_expected_stop_column_number(self):
"""Return the 1-based column number of the first non-whitespace
character in the breakpoint source line."""
stop_line = get_line(self.SOURCE_FILE, self.line)
# The number of spaces that must be skipped to get to the first non-
# whitespace character --- where we expect the debugger breakpoint
# column to be --- is equal to the number of characters that get
# stripped off the front when we lstrip it, plus one to specify
# the character column after the initial whitespace.
return len(stop_line) - len(stop_line.lstrip()) + 1
def do_display_source_python_api(self, use_color, column_marker_regex):
Merge dwarf and dsym tests Currently most of the test files have a separate dwarf and a separate dsym test with almost identical content (only the build step is different). With adding dwo symbol file handling to the test suit it would increase this to a 3-way duplication. The purpose of this change is to eliminate this redundancy with generating 2 test case (one dwarf and one dsym) for each test function specified (dwo handling will be added at a later commit). Main design goals: * There should be no boilerplate code in each test file to support the multiple debug info in most of the tests (custom scenarios are acceptable in special cases) so adding a new test case is easier and we can't miss one of the debug info type. * In case of a test failure, the debug symbols used during the test run have to be cleanly visible from the output of dotest.py to make debugging easier both from build bot logs and from local test runs * Each test case should have a unique, fully qualified name so we can run exactly 1 test with "-f <test-case>.<test-function>" syntax * Test output should be grouped based on test files the same way as it happens now (displaying dwarf/dsym results separately isn't preferable) Proposed solution (main logic in lldbtest.py, rest of them are test cases fixed up for the new style): * Have only 1 test fuction in the test files what will run for all debug info separately and this test function should call just "self.build(...)" to build an inferior with the right debug info * When a class is created by python (the class object, not the class instance), we will generate a new test method for each debug info format in the test class with the name "<test-function>_<debug-info>" and remove the original test method. This way unittest2 see multiple test methods (1 for each debug info, pretty much as of now) and will handle the test selection and the failure reporting correctly (the debug info will be visible from the end of the test name) * Add new annotation @no_debug_info_test to disable the generation of multiple tests for each debug info format when the test don't have an inferior Differential revision: http://reviews.llvm.org/D13028 llvm-svn: 248883
2015-09-30 18:12:40 +08:00
self.build()
exe = self.getBuildArtifact("a.out")
self.runCmd("file " + exe, CURRENT_EXECUTABLE_SET)
target = self.dbg.CreateTarget(exe)
self.assertTrue(target, VALID_TARGET)
# Launch the process, and do not stop at the entry point.
add stop column highlighting support This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
2016-09-22 04:13:14 +08:00
args = None
envp = None
process = target.LaunchSimple(
add stop column highlighting support This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
2016-09-22 04:13:14 +08:00
args, envp, self.get_process_working_directory())
self.assertIsNotNone(process)
#
# Exercise Python APIs to display source lines.
#
add stop column highlighting support This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
2016-09-22 04:13:14 +08:00
# Setup whether we should use ansi escape sequences, including color
# and styles such as underline.
self.dbg.SetUseColor(use_color)
# Create the filespec for 'main.c'.
filespec = lldb.SBFileSpec('main.c', False)
source_mgr = self.dbg.GetSourceManager()
# Use a string stream as the destination.
stream = lldb.SBStream()
add stop column highlighting support This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
2016-09-22 04:13:14 +08:00
column = self.get_expected_stop_column_number()
context_before = 2
context_after = 2
current_line_prefix = "=>"
source_mgr.DisplaySourceLinesWithLineNumbersAndColumn(
filespec, self.line, column, context_before, context_after,
current_line_prefix, stream)
# 2
# 3 int main(int argc, char const *argv[]) {
# => 4 printf("Hello world.\n"); // Set break point at this line.
# 5 return 0;
# 6 }
self.expect(stream.GetData(), "Source code displayed correctly",
exe=False,
add stop column highlighting support This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
2016-09-22 04:13:14 +08:00
patterns=['=> %d.*Hello world' % self.line,
column_marker_regex])
# Boundary condition testings for SBStream(). LLDB should not crash!
stream.Print(None)
stream.RedirectToFile(None, True)
add stop column highlighting support This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
2016-09-22 04:13:14 +08:00
@add_test_categories(['pyapi'])
def test_display_source_python_dumb_terminal(self):
"""Test display of source using the SBSourceManager API, using a
dumb terminal and thus no color support (the default)."""
use_color = False
self.do_display_source_python_api(use_color, r"\s+\^")
@add_test_categories(['pyapi'])
def test_display_source_python_ansi_terminal(self):
"""Test display of source using the SBSourceManager API, using a
dumb terminal and thus no color support (the default)."""
use_color = True
underline_regex = ansi_underline_surround_regex(r".")
self.do_display_source_python_api(use_color, underline_regex)
Merge dwarf and dsym tests Currently most of the test files have a separate dwarf and a separate dsym test with almost identical content (only the build step is different). With adding dwo symbol file handling to the test suit it would increase this to a 3-way duplication. The purpose of this change is to eliminate this redundancy with generating 2 test case (one dwarf and one dsym) for each test function specified (dwo handling will be added at a later commit). Main design goals: * There should be no boilerplate code in each test file to support the multiple debug info in most of the tests (custom scenarios are acceptable in special cases) so adding a new test case is easier and we can't miss one of the debug info type. * In case of a test failure, the debug symbols used during the test run have to be cleanly visible from the output of dotest.py to make debugging easier both from build bot logs and from local test runs * Each test case should have a unique, fully qualified name so we can run exactly 1 test with "-f <test-case>.<test-function>" syntax * Test output should be grouped based on test files the same way as it happens now (displaying dwarf/dsym results separately isn't preferable) Proposed solution (main logic in lldbtest.py, rest of them are test cases fixed up for the new style): * Have only 1 test fuction in the test files what will run for all debug info separately and this test function should call just "self.build(...)" to build an inferior with the right debug info * When a class is created by python (the class object, not the class instance), we will generate a new test method for each debug info format in the test class with the name "<test-function>_<debug-info>" and remove the original test method. This way unittest2 see multiple test methods (1 for each debug info, pretty much as of now) and will handle the test selection and the failure reporting correctly (the debug info will be visible from the end of the test name) * Add new annotation @no_debug_info_test to disable the generation of multiple tests for each debug info format when the test don't have an inferior Differential revision: http://reviews.llvm.org/D13028 llvm-svn: 248883
2015-09-30 18:12:40 +08:00
def test_move_and_then_display_source(self):
"""Test that target.source-map settings work by moving main.c to hidden/main.c."""
Merge dwarf and dsym tests Currently most of the test files have a separate dwarf and a separate dsym test with almost identical content (only the build step is different). With adding dwo symbol file handling to the test suit it would increase this to a 3-way duplication. The purpose of this change is to eliminate this redundancy with generating 2 test case (one dwarf and one dsym) for each test function specified (dwo handling will be added at a later commit). Main design goals: * There should be no boilerplate code in each test file to support the multiple debug info in most of the tests (custom scenarios are acceptable in special cases) so adding a new test case is easier and we can't miss one of the debug info type. * In case of a test failure, the debug symbols used during the test run have to be cleanly visible from the output of dotest.py to make debugging easier both from build bot logs and from local test runs * Each test case should have a unique, fully qualified name so we can run exactly 1 test with "-f <test-case>.<test-function>" syntax * Test output should be grouped based on test files the same way as it happens now (displaying dwarf/dsym results separately isn't preferable) Proposed solution (main logic in lldbtest.py, rest of them are test cases fixed up for the new style): * Have only 1 test fuction in the test files what will run for all debug info separately and this test function should call just "self.build(...)" to build an inferior with the right debug info * When a class is created by python (the class object, not the class instance), we will generate a new test method for each debug info format in the test class with the name "<test-function>_<debug-info>" and remove the original test method. This way unittest2 see multiple test methods (1 for each debug info, pretty much as of now) and will handle the test selection and the failure reporting correctly (the debug info will be visible from the end of the test name) * Add new annotation @no_debug_info_test to disable the generation of multiple tests for each debug info format when the test don't have an inferior Differential revision: http://reviews.llvm.org/D13028 llvm-svn: 248883
2015-09-30 18:12:40 +08:00
self.build()
exe = self.getBuildArtifact("a.out")
self.runCmd("file " + exe, CURRENT_EXECUTABLE_SET)
# Move main.c to hidden/main.c.
main_c = "main.c"
main_c_hidden = os.path.join("hidden", main_c)
os.rename(main_c, main_c_hidden)
# Restore main.c after the test.
self.addTearDownHook(lambda: os.rename(main_c_hidden, main_c))
if self.TraceOn():
system([["ls"]])
system([["ls", "hidden"]])
# Set source remapping with invalid replace path and verify we get an
# error
self.expect(
"settings set target.source-map /a/b/c/d/e /q/r/s/t/u",
error=True,
substrs=['''error: the replacement path doesn't exist: "/q/r/s/t/u"'''])
# Set target.source-map settings.
self.runCmd("settings set target.source-map %s %s" %
(self.getSourceDir(),
os.path.join(self.getSourceDir(), "hidden")))
# And verify that the settings work.
self.expect("settings show target.source-map",
substrs=[self.getSourceDir(),
os.path.join(self.getSourceDir(), "hidden")])
# Display main() and verify that the source mapping has been kicked in.
self.expect("source list -n main", SOURCE_DISPLAYED_CORRECTLY,
substrs=['Hello world'])
Merge dwarf and dsym tests Currently most of the test files have a separate dwarf and a separate dsym test with almost identical content (only the build step is different). With adding dwo symbol file handling to the test suit it would increase this to a 3-way duplication. The purpose of this change is to eliminate this redundancy with generating 2 test case (one dwarf and one dsym) for each test function specified (dwo handling will be added at a later commit). Main design goals: * There should be no boilerplate code in each test file to support the multiple debug info in most of the tests (custom scenarios are acceptable in special cases) so adding a new test case is easier and we can't miss one of the debug info type. * In case of a test failure, the debug symbols used during the test run have to be cleanly visible from the output of dotest.py to make debugging easier both from build bot logs and from local test runs * Each test case should have a unique, fully qualified name so we can run exactly 1 test with "-f <test-case>.<test-function>" syntax * Test output should be grouped based on test files the same way as it happens now (displaying dwarf/dsym results separately isn't preferable) Proposed solution (main logic in lldbtest.py, rest of them are test cases fixed up for the new style): * Have only 1 test fuction in the test files what will run for all debug info separately and this test function should call just "self.build(...)" to build an inferior with the right debug info * When a class is created by python (the class object, not the class instance), we will generate a new test method for each debug info format in the test class with the name "<test-function>_<debug-info>" and remove the original test method. This way unittest2 see multiple test methods (1 for each debug info, pretty much as of now) and will handle the test selection and the failure reporting correctly (the debug info will be visible from the end of the test name) * Add new annotation @no_debug_info_test to disable the generation of multiple tests for each debug info format when the test don't have an inferior Differential revision: http://reviews.llvm.org/D13028 llvm-svn: 248883
2015-09-30 18:12:40 +08:00
def test_modify_source_file_while_debugging(self):
"""Modify a source file while debugging the executable."""
Merge dwarf and dsym tests Currently most of the test files have a separate dwarf and a separate dsym test with almost identical content (only the build step is different). With adding dwo symbol file handling to the test suit it would increase this to a 3-way duplication. The purpose of this change is to eliminate this redundancy with generating 2 test case (one dwarf and one dsym) for each test function specified (dwo handling will be added at a later commit). Main design goals: * There should be no boilerplate code in each test file to support the multiple debug info in most of the tests (custom scenarios are acceptable in special cases) so adding a new test case is easier and we can't miss one of the debug info type. * In case of a test failure, the debug symbols used during the test run have to be cleanly visible from the output of dotest.py to make debugging easier both from build bot logs and from local test runs * Each test case should have a unique, fully qualified name so we can run exactly 1 test with "-f <test-case>.<test-function>" syntax * Test output should be grouped based on test files the same way as it happens now (displaying dwarf/dsym results separately isn't preferable) Proposed solution (main logic in lldbtest.py, rest of them are test cases fixed up for the new style): * Have only 1 test fuction in the test files what will run for all debug info separately and this test function should call just "self.build(...)" to build an inferior with the right debug info * When a class is created by python (the class object, not the class instance), we will generate a new test method for each debug info format in the test class with the name "<test-function>_<debug-info>" and remove the original test method. This way unittest2 see multiple test methods (1 for each debug info, pretty much as of now) and will handle the test selection and the failure reporting correctly (the debug info will be visible from the end of the test name) * Add new annotation @no_debug_info_test to disable the generation of multiple tests for each debug info format when the test don't have an inferior Differential revision: http://reviews.llvm.org/D13028 llvm-svn: 248883
2015-09-30 18:12:40 +08:00
self.build()
exe = self.getBuildArtifact("a.out")
self.runCmd("file " + exe, CURRENT_EXECUTABLE_SET)
lldbutil.run_break_set_by_file_and_line(
self, "main.c", self.line, num_expected_locations=1, loc_exact=True)
self.runCmd("run", RUN_SUCCEEDED)
# The stop reason of the thread should be breakpoint.
self.expect("thread list", STOPPED_DUE_TO_BREAKPOINT,
substrs=['stopped',
'main.c:%d' % self.line,
'stop reason = breakpoint'])
# Display some source code.
self.expect(
"source list -f main.c -l %d" %
self.line,
SOURCE_DISPLAYED_CORRECTLY,
substrs=['Hello world'])
# The '-b' option shows the line table locations from the debug information
# that indicates valid places to set source level breakpoints.
# The file to display is implicit in this case.
self.runCmd("source list -l %d -c 3 -b" % self.line)
output = self.res.GetOutput().splitlines()[0]
# If the breakpoint set command succeeded, we should expect a positive number
# of breakpoints for the current line, i.e., self.line.
import re
m = re.search('^\[(\d+)\].*// Set break point at this line.', output)
if not m:
self.fail("Fail to display source level breakpoints")
self.assertTrue(int(m.group(1)) > 0)
# Read the main.c file content.
with io.open('main.c', 'r', newline='\n') as f:
original_content = f.read()
if self.TraceOn():
print("original content:", original_content)
# Modify the in-memory copy of the original source code.
new_content = original_content.replace('Hello world', 'Hello lldb', 1)
# This is the function to restore the original content.
def restore_file():
#print("os.path.getmtime() before restore:", os.path.getmtime('main.c'))
Add the ability for the test suite to specify a list of compilers and a list of architectures on the command line. For example, use '-A x86_64^i386' to launch the inferior use both x86_64 and i386. This is an example of building the debuggee using both clang and gcc compiers: [17:30:46] johnny:/Volumes/data/lldb/svn/trunk/test $ ./dotest.py -C clang^gcc -v -f SourceManagerTestCase.test_modify_source_file_while_debugging Session logs for test failures/errors will go into directory '2011-03-03-17_31_39' Command invoked: python ./dotest.py -C clang^gcc -v -f SourceManagerTestCase.test_modify_source_file_while_debugging Configuration: compiler=clang ---------------------------------------------------------------------- Collected 1 test 1: test_modify_source_file_while_debugging (TestSourceManager.SourceManagerTestCase) Modify a source file while debugging the executable. ... Command 'run' failed! original content: #include <stdio.h> int main(int argc, char const *argv[]) { printf("Hello world.\n"); // Set break point at this line. return 0; } new content: #include <stdio.h> int main(int argc, char const *argv[]) { printf("Hello lldb.\n"); // Set break point at this line. return 0; } os.path.getmtime() after writing new content: 1299202305.0 content restored to: #include <stdio.h> int main(int argc, char const *argv[]) { printf("Hello world.\n"); // Set break point at this line. return 0; } os.path.getmtime() after restore: 1299202307.0 ok ---------------------------------------------------------------------- Ran 1 test in 8.259s OK Configuration: compiler=gcc ---------------------------------------------------------------------- Collected 1 test 1: test_modify_source_file_while_debugging (TestSourceManager.SourceManagerTestCase) Modify a source file while debugging the executable. ... original content: #include <stdio.h> int main(int argc, char const *argv[]) { printf("Hello world.\n"); // Set break point at this line. return 0; } new content: #include <stdio.h> int main(int argc, char const *argv[]) { printf("Hello lldb.\n"); // Set break point at this line. return 0; } os.path.getmtime() after writing new content: 1299202307.0 content restored to: #include <stdio.h> int main(int argc, char const *argv[]) { printf("Hello world.\n"); // Set break point at this line. return 0; } os.path.getmtime() after restore: 1299202309.0 ok ---------------------------------------------------------------------- Ran 1 test in 2.301s OK [17:31:49] johnny:/Volumes/data/lldb/svn/trunk/test $ llvm-svn: 126979
2011-03-04 09:35:22 +08:00
time.sleep(1)
with io.open('main.c', 'w', newline='\n') as f:
f.write(original_content)
if self.TraceOn():
with open('main.c', 'r') as f:
print("content restored to:", f.read())
Add the ability for the test suite to specify a list of compilers and a list of architectures on the command line. For example, use '-A x86_64^i386' to launch the inferior use both x86_64 and i386. This is an example of building the debuggee using both clang and gcc compiers: [17:30:46] johnny:/Volumes/data/lldb/svn/trunk/test $ ./dotest.py -C clang^gcc -v -f SourceManagerTestCase.test_modify_source_file_while_debugging Session logs for test failures/errors will go into directory '2011-03-03-17_31_39' Command invoked: python ./dotest.py -C clang^gcc -v -f SourceManagerTestCase.test_modify_source_file_while_debugging Configuration: compiler=clang ---------------------------------------------------------------------- Collected 1 test 1: test_modify_source_file_while_debugging (TestSourceManager.SourceManagerTestCase) Modify a source file while debugging the executable. ... Command 'run' failed! original content: #include <stdio.h> int main(int argc, char const *argv[]) { printf("Hello world.\n"); // Set break point at this line. return 0; } new content: #include <stdio.h> int main(int argc, char const *argv[]) { printf("Hello lldb.\n"); // Set break point at this line. return 0; } os.path.getmtime() after writing new content: 1299202305.0 content restored to: #include <stdio.h> int main(int argc, char const *argv[]) { printf("Hello world.\n"); // Set break point at this line. return 0; } os.path.getmtime() after restore: 1299202307.0 ok ---------------------------------------------------------------------- Ran 1 test in 8.259s OK Configuration: compiler=gcc ---------------------------------------------------------------------- Collected 1 test 1: test_modify_source_file_while_debugging (TestSourceManager.SourceManagerTestCase) Modify a source file while debugging the executable. ... original content: #include <stdio.h> int main(int argc, char const *argv[]) { printf("Hello world.\n"); // Set break point at this line. return 0; } new content: #include <stdio.h> int main(int argc, char const *argv[]) { printf("Hello lldb.\n"); // Set break point at this line. return 0; } os.path.getmtime() after writing new content: 1299202307.0 content restored to: #include <stdio.h> int main(int argc, char const *argv[]) { printf("Hello world.\n"); // Set break point at this line. return 0; } os.path.getmtime() after restore: 1299202309.0 ok ---------------------------------------------------------------------- Ran 1 test in 2.301s OK [17:31:49] johnny:/Volumes/data/lldb/svn/trunk/test $ llvm-svn: 126979
2011-03-04 09:35:22 +08:00
# Touch the file just to be sure.
os.utime('main.c', None)
if self.TraceOn():
print(
"os.path.getmtime() after restore:",
os.path.getmtime('main.c'))
Add the ability for the test suite to specify a list of compilers and a list of architectures on the command line. For example, use '-A x86_64^i386' to launch the inferior use both x86_64 and i386. This is an example of building the debuggee using both clang and gcc compiers: [17:30:46] johnny:/Volumes/data/lldb/svn/trunk/test $ ./dotest.py -C clang^gcc -v -f SourceManagerTestCase.test_modify_source_file_while_debugging Session logs for test failures/errors will go into directory '2011-03-03-17_31_39' Command invoked: python ./dotest.py -C clang^gcc -v -f SourceManagerTestCase.test_modify_source_file_while_debugging Configuration: compiler=clang ---------------------------------------------------------------------- Collected 1 test 1: test_modify_source_file_while_debugging (TestSourceManager.SourceManagerTestCase) Modify a source file while debugging the executable. ... Command 'run' failed! original content: #include <stdio.h> int main(int argc, char const *argv[]) { printf("Hello world.\n"); // Set break point at this line. return 0; } new content: #include <stdio.h> int main(int argc, char const *argv[]) { printf("Hello lldb.\n"); // Set break point at this line. return 0; } os.path.getmtime() after writing new content: 1299202305.0 content restored to: #include <stdio.h> int main(int argc, char const *argv[]) { printf("Hello world.\n"); // Set break point at this line. return 0; } os.path.getmtime() after restore: 1299202307.0 ok ---------------------------------------------------------------------- Ran 1 test in 8.259s OK Configuration: compiler=gcc ---------------------------------------------------------------------- Collected 1 test 1: test_modify_source_file_while_debugging (TestSourceManager.SourceManagerTestCase) Modify a source file while debugging the executable. ... original content: #include <stdio.h> int main(int argc, char const *argv[]) { printf("Hello world.\n"); // Set break point at this line. return 0; } new content: #include <stdio.h> int main(int argc, char const *argv[]) { printf("Hello lldb.\n"); // Set break point at this line. return 0; } os.path.getmtime() after writing new content: 1299202307.0 content restored to: #include <stdio.h> int main(int argc, char const *argv[]) { printf("Hello world.\n"); // Set break point at this line. return 0; } os.path.getmtime() after restore: 1299202309.0 ok ---------------------------------------------------------------------- Ran 1 test in 2.301s OK [17:31:49] johnny:/Volumes/data/lldb/svn/trunk/test $ llvm-svn: 126979
2011-03-04 09:35:22 +08:00
# Modify the source code file.
with io.open('main.c', 'w', newline='\n') as f:
Add the ability for the test suite to specify a list of compilers and a list of architectures on the command line. For example, use '-A x86_64^i386' to launch the inferior use both x86_64 and i386. This is an example of building the debuggee using both clang and gcc compiers: [17:30:46] johnny:/Volumes/data/lldb/svn/trunk/test $ ./dotest.py -C clang^gcc -v -f SourceManagerTestCase.test_modify_source_file_while_debugging Session logs for test failures/errors will go into directory '2011-03-03-17_31_39' Command invoked: python ./dotest.py -C clang^gcc -v -f SourceManagerTestCase.test_modify_source_file_while_debugging Configuration: compiler=clang ---------------------------------------------------------------------- Collected 1 test 1: test_modify_source_file_while_debugging (TestSourceManager.SourceManagerTestCase) Modify a source file while debugging the executable. ... Command 'run' failed! original content: #include <stdio.h> int main(int argc, char const *argv[]) { printf("Hello world.\n"); // Set break point at this line. return 0; } new content: #include <stdio.h> int main(int argc, char const *argv[]) { printf("Hello lldb.\n"); // Set break point at this line. return 0; } os.path.getmtime() after writing new content: 1299202305.0 content restored to: #include <stdio.h> int main(int argc, char const *argv[]) { printf("Hello world.\n"); // Set break point at this line. return 0; } os.path.getmtime() after restore: 1299202307.0 ok ---------------------------------------------------------------------- Ran 1 test in 8.259s OK Configuration: compiler=gcc ---------------------------------------------------------------------- Collected 1 test 1: test_modify_source_file_while_debugging (TestSourceManager.SourceManagerTestCase) Modify a source file while debugging the executable. ... original content: #include <stdio.h> int main(int argc, char const *argv[]) { printf("Hello world.\n"); // Set break point at this line. return 0; } new content: #include <stdio.h> int main(int argc, char const *argv[]) { printf("Hello lldb.\n"); // Set break point at this line. return 0; } os.path.getmtime() after writing new content: 1299202307.0 content restored to: #include <stdio.h> int main(int argc, char const *argv[]) { printf("Hello world.\n"); // Set break point at this line. return 0; } os.path.getmtime() after restore: 1299202309.0 ok ---------------------------------------------------------------------- Ran 1 test in 2.301s OK [17:31:49] johnny:/Volumes/data/lldb/svn/trunk/test $ llvm-svn: 126979
2011-03-04 09:35:22 +08:00
time.sleep(1)
f.write(new_content)
if self.TraceOn():
print("new content:", new_content)
print(
"os.path.getmtime() after writing new content:",
os.path.getmtime('main.c'))
# Add teardown hook to restore the file to the original content.
self.addTearDownHook(restore_file)
# Display the source code again. We should see the updated line.
self.expect(
"source list -f main.c -l %d" %
self.line,
SOURCE_DISPLAYED_CORRECTLY,
substrs=['Hello lldb'])
def test_set_breakpoint_with_absolute_path(self):
self.build()
self.runCmd("settings set target.source-map %s %s" %
(self.getSourceDir(),
os.path.join(self.getSourceDir(), "hidden")))
exe = self.getBuildArtifact("a.out")
main = os.path.join(self.getSourceDir(), "hidden", "main.c")
self.runCmd("file " + exe, CURRENT_EXECUTABLE_SET)
lldbutil.run_break_set_by_file_and_line(
self, main, self.line, num_expected_locations=1, loc_exact=False)
self.runCmd("run", RUN_SUCCEEDED)
# The stop reason of the thread should be breakpoint.
self.expect("thread list", STOPPED_DUE_TO_BREAKPOINT,
substrs=['stopped',
'main.c:%d' % self.line,
'stop reason = breakpoint'])