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

173 lines
6.7 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
import lldb
from lldbsuite.test.decorators import *
from lldbsuite.test.lldbtest import *
from lldbsuite.test import lldbutil
class SourceManagerTestCase(TestBase):
mydir = TestBase.compute_mydir(__file__)
def setUp(self):
# Call super's setUp().
TestBase.setUp(self)
# Find the line number to break inside main().
self.line = line_number('main.c', '// Set break point at this line.')
@add_test_categories(['pyapi'])
def test_display_source_python(self):
"""Test display of source using the SBSourceManager API."""
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 10:12:40 +00:00
self.build()
exe = os.path.join(os.getcwd(), "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.
process = target.LaunchSimple (None, None, self.get_process_working_directory())
#
# Exercise Python APIs to display source lines.
#
# 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()
source_mgr.DisplaySourceLinesWithLineNumbers(filespec,
self.line,
2, # context before
2, # context after
"=>", # prefix for current line
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,
patterns = ['=> %d.*Hello world' % self.line])
# Boundary condition testings for SBStream(). LLDB should not crash!
stream.Print(None)
stream.RedirectToFile(None, True)
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 10:12:40 +00: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 10:12:40 +00:00
self.build()
exe = os.path.join(os.getcwd(), "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 target.source-map settings.
self.runCmd("settings set target.source-map %s %s" % (os.getcwd(), os.path.join(os.getcwd(), "hidden")))
# And verify that the settings work.
self.expect("settings show target.source-map",
substrs = [os.getcwd(), os.path.join(os.getcwd(), "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 10:12:40 +00: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 10:12:40 +00:00
self.build()
exe = os.path.join(os.getcwd(), "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,
Centralized a lot of the status information for processes, threads, and stack frame down in the lldb_private::Process, lldb_private::Thread, lldb_private::StackFrameList and the lldb_private::StackFrame classes. We had some command line commands that had duplicate versions of the process status output ("thread list" and "process status" for example). Removed the "file" command and placed it where it should have been: "target create". Made an alias for "file" to "target create" so we stay compatible with GDB commands. We can now have multple usable targets in lldb at the same time. This is nice for comparing two runs of a program or debugging more than one binary at the same time. The new command is "target select <target-idx>" and also to see a list of the current targets you can use the new "target list" command. The flow in a debug session can be: (lldb) target create /path/to/exe/a.out (lldb) breakpoint set --name main (lldb) run ... hit breakpoint (lldb) target create /bin/ls (lldb) run /tmp Process 36001 exited with status = 0 (0x00000000) (lldb) target list Current targets: target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) * target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) target select 0 Current targets: * target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) bt * thread #1: tid = 0x2d03, 0x0000000100000b9a a.out`main + 42 at main.c:16, stop reason = breakpoint 1.1 frame #0: 0x0000000100000b9a a.out`main + 42 at main.c:16 frame #1: 0x0000000100000b64 a.out`start + 52 Above we created a target for "a.out" and ran and hit a breakpoint at "main". Then we created a new target for /bin/ls and ran it. Then we listed the targest and selected our original "a.out" program, so we showed two concurent debug sessions going on at the same time. llvm-svn: 129695
2011-04-18 08:33:37 +00:00
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 01:35:22 +00: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 01:35:22 +00: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 01:35:22 +00: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 01:35:22 +00: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'])