[llvm-dev] PSA: debuginfo-tests workflow changing slightly
Don Hinton via llvm-dev
llvm-dev at lists.llvm.org
Sat Nov 25 15:46:50 PST 2017
Hi Zachary:
I was able to reproduce the greendragon results locally (OSX), and fix the
problem by excluding 'debuginfo-tests' from check-clang -- this prevents
them from being added twice, once for check-clang and again for
check-debuginfo.
Below are the minimized patches I used to reproduce and fix the problem --
based on your originals.
I've verified these patches work when including debuginfo-tests in either
clang/test or llvm/projects.
hth...
don
local:/Users/dhinton/projects/llvm_project/llvm/tools/clang $ git diff
master
diff --git a/test/CMakeLists.txt b/test/CMakeLists.txt
index c1ac9e4f0f..8c2db7600d 100644
--- a/test/CMakeLists.txt
+++ b/test/CMakeLists.txt
@@ -131,3 +131,7 @@ add_lit_testsuites(CLANG ${CMAKE_CURRENT_SOURCE_DIR}
add_custom_target(clang-test)
add_dependencies(clang-test check-clang)
set_target_properties(clang-test PROPERTIES FOLDER "Clang tests")
+
+if (EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/debuginfo-tests/CMakeLists.txt")
+ add_subdirectory(debuginfo-tests)
+endif()
diff --git a/test/lit.cfg.py b/test/lit.cfg.py
index 39bdf36afd..5323cfe735 100644
--- a/test/lit.cfg.py
+++ b/test/lit.cfg.py
@@ -31,7 +31,7 @@ config.suffixes = ['.c', '.cpp', '.cppm', '.m', '.mm',
'.cu',
# excludes: A list of directories to exclude from the testsuite. The
'Inputs'
# subdirectories contain auxiliary inputs for various tests in their parent
# directories.
-config.excludes = ['Inputs', 'CMakeLists.txt', 'README.txt', 'LICENSE.txt']
+config.excludes = ['Inputs', 'CMakeLists.txt', 'README.txt',
'LICENSE.txt', 'debuginfo-tests']
# test_source_root: The root path where tests are located.
config.test_source_root = os.path.dirname(__file__)
@@ -58,8 +58,6 @@ tool_dirs = [config.clang_tools_dir,
config.llvm_tools_dir]
tools = [
'c-index-test', 'clang-check', 'clang-diff', 'clang-format', 'opt',
- ToolSubst('%test_debuginfo', command=os.path.join(
- config.llvm_src_root, 'utils', 'test_debuginfo.pl')),
ToolSubst('%clang_func_map', command=FindTool(
'clang-func-mapping'), unresolved='ignore'),
]
local:/Users/dhinton/projects/llvm_project/debuginfo-tests $ git diff master
diff --git a/CMakeLists.txt b/CMakeLists.txt
new file mode 100644
index 0000000..87260f1
--- /dev/null
+++ b/CMakeLists.txt
@@ -0,0 +1,26 @@
+# Debug Info tests. These tests invoke clang to generate programs with
+# various types of debug info, and then run those programs under a debugger
+# such as GDB or LLDB to verify the results.
+
+set(DEBUGINFO_TESTS_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR})
+set(DEBUGINFO_TESTS_BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR})
+
+set(DEBUGINFO_TEST_DEPS
+ clang
+ FileCheck
+ count
+ not
+ )
+
+configure_lit_site_cfg(
+ ${CMAKE_CURRENT_SOURCE_DIR}/lit.site.cfg.py.in
+ ${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg.py
+ MAIN_CONFIG
+ ${CMAKE_CURRENT_SOURCE_DIR}/lit.cfg.py
+ )
+
+add_lit_testsuite(check-debuginfo "Running debug info integration tests"
+ ${CMAKE_CURRENT_BINARY_DIR}
+ DEPENDS ${DEBUGINFO_TEST_DEPS}
+ )
+set_target_properties(check-debuginfo PROPERTIES FOLDER "Debug info tests")
diff --git a/lit.cfg.py b/lit.cfg.py
new file mode 100644
index 0000000..ad65f46
--- /dev/null
+++ b/lit.cfg.py
@@ -0,0 +1,59 @@
+# -*- Python -*-
+
+import os
+import platform
+import re
+import subprocess
+import tempfile
+
+import lit.formats
+import lit.util
+
+from lit.llvm import llvm_config
+from lit.llvm.subst import ToolSubst
+from lit.llvm.subst import FindTool
+
+# Configuration file for the 'lit' test runner.
+
+# name: The name of this test suite.
+config.name = 'debuginfo-tests'
+
+# testFormat: The test format to use to interpret tests.
+#
+# For now we require '&&' between commands, until they get globally killed and
+# the test runner updated.
+config.test_format = lit.formats.ShTest(not llvm_config.use_lit_shell)
+
+# suffixes: A list of file extensions to treat as test files.
+config.suffixes = ['.c', '.cpp', '.m']
+
+# excludes: A list of directories to exclude from the testsuite. The 'Inputs'
+# subdirectories contain auxiliary inputs for various tests in their parent
+# directories.
+config.excludes = ['Inputs']
+
+# test_source_root: The root path where tests are located.
+config.test_source_root = os.path.join(config.debuginfo_tests_src_root)
+
+# test_exec_root: The root path where tests should be run.
+config.test_exec_root = config.debuginfo_tests_obj_root
+
+llvm_config.use_default_substitutions()
+
+llvm_config.use_clang()
+
+if config.llvm_use_sanitizer:
+ # Propagate path to symbolizer for ASan/MSan.
+ llvm_config.with_system_environment(
+ ['ASAN_SYMBOLIZER_PATH', 'MSAN_SYMBOLIZER_PATH'])
+
+tool_dirs = [config.llvm_tools_dir]
+
+tools = [
+ ToolSubst('%test_debuginfo', command=os.path.join(
+ config.debuginfo_tests_src_root, 'test_debuginfo.pl')),
+]
+
+llvm_config.add_tool_substitutions(tools, tool_dirs)
+
+lit.util.usePlatformSdkOnDarwin(config, lit_config)
diff --git a/lit.site.cfg.py.in b/lit.site.cfg.py.in
new file mode 100644
index 0000000..8c4481a
--- /dev/null
+++ b/lit.site.cfg.py.in
@@ -0,0 +1,25 @@
+ at LIT_SITE_CFG_IN_HEADER@
+
+import lit.util
+
+config.test_exec_root = "@CMAKE_BINARY_DIR@"
+
+config.llvm_src_root = "@LLVM_SOURCE_DIR@"
+config.llvm_obj_root = "@LLVM_BINARY_DIR@"
+config.llvm_tools_dir = "@LLVM_TOOLS_DIR@"
+config.llvm_libs_dir = "@LLVM_LIBS_DIR@"
+config.llvm_shlib_dir = "@SHLIBDIR@"
+config.llvm_plugin_ext = "@LLVM_PLUGIN_EXT@"
+config.debuginfo_tests_obj_root = "@DEBUGINFO_TESTS_BINARY_DIR@"
+config.debuginfo_tests_src_root = "@DEBUGINFO_TESTS_SOURCE_DIR@"
+config.has_lld = lit.util.pythonize_bool("@DEBUGINFO_TESTS_HAS_LLD@")
+config.host_triple = "@LLVM_HOST_TRIPLE@"
+config.target_triple = "@TARGET_TRIPLE@"
+config.host_arch = "@HOST_ARCH@"
+
+config.llvm_use_sanitizer = "@LLVM_USE_SANITIZER@"
+
+ at LIT_SITE_CFG_IN_FOOTER@
+
+# Let the main config do the real work.
+lit_config.load_config(config, "@DEBUGINFO_TESTS_SOURCE_DIR@/lit.cfg.py")
diff --git a/test_debuginfo.pl b/test_debuginfo.pl
new file mode 100755
index 0000000..adc11c3
--- /dev/null
+++ b/test_debuginfo.pl
@@ -0,0 +1,80 @@
+#!/usr/bin/perl
+#
+# This script tests debugging information generated by a compiler.
+# Input arguments
+# - Input source program. Usually this source file is decorated using
+# special comments to communicate debugger commands.
+# - Executable file. This file is generated by the compiler.
+#
+# This perl script extracts debugger commands from input source program
+# comments in a script. A debugger is used to load the executable file
+# and run the script generated from source program comments. Finally,
+# the debugger output is checked, using FileCheck, to validate
+# debugging information.
+#
+# On Darwin the default is to use the llgdb.py wrapper script which
+# translates gdb commands into their lldb equivalents.
+
+use File::Basename;
+use Config;
+use Cwd;
+
+my $testcase_file = $ARGV[0];
+my $executable_file = $ARGV[1];
+
+my $input_filename = basename $testcase_file;
+my $output_dir = dirname $executable_file;
+
+my $debugger_script_file = "$output_dir/$input_filename.debugger.script";
+my $output_file = "$output_dir/$input_filename.gdb.output";
+
+my %cmd_map = ();
+# Assume lldb to be the debugger on Darwin.
+my $use_lldb = 0;
+$use_lldb = 1 if ($Config{osname} eq "darwin");
+
+# Extract debugger commands from testcase. They are marked with DEBUGGER:
+# at the beginning of a comment line.
+open(INPUT, $testcase_file);
+open(OUTPUT, ">$debugger_script_file");
+while(<INPUT>) {
+ my($line) = $_;
+ $i = index($line, "DEBUGGER:");
+ if ( $i >= 0) {
+ $l = length("DEBUGGER:");
+ $s = substr($line, $i + $l);
+ print OUTPUT "$s";
+ }
+}
+print OUTPUT "\n";
+print OUTPUT "quit\n";
+close(INPUT);
+close(OUTPUT);
+
+# setup debugger and debugger options to run a script.
+my $my_debugger = $ENV{'DEBUGGER'};
+if (!$my_debugger) {
+ if ($use_lldb) {
+ my $path = dirname(Cwd::abs_path($0));
+ $my_debugger = "/usr/bin/env python $path/llgdb.py";
+ } else {
+ $my_debugger = "gdb";
+ }
+}
+
+# quiet / exit after cmdline / no init file / execute script
+my $debugger_options = "-q -batch -n -x";
+
+# run debugger and capture output.
+system("$my_debugger $debugger_options $debugger_script_file
$executable_file > $output_file 2>&1");
+
+# validate output.
+system("FileCheck", "-input-file", "$output_file", "$testcase_file");
+if ($?>>8 == 1) {
+ print "Debugger output was:\n";
+ system("cat", "$output_file");
+ exit 1;
+}
+else {
+ exit 0;
+}
local:/Users/dhinton/projects/llvm_project/llvm $ git diff master
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 8cd9d053c63..7d0fe05b511 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -110,7 +110,7 @@ endif()
# LLVM_EXTERNAL_${project}_SOURCE_DIR using LLVM_ALL_PROJECTS
# This allows an easy way of setting up a build directory for llvm and another
# one for llvm+clang+... using the same sources.
-set(LLVM_ALL_PROJECTS "clang;libcxx;libcxxabi;lldb;compiler-rt;lld;polly")
+set(LLVM_ALL_PROJECTS
"clang;libcxx;libcxxabi;lldb;compiler-rt;lld;polly,debuginfo-tests")
set(LLVM_ENABLE_PROJECTS "" CACHE STRING
"Semicolon-separated list of projects to build
(${LLVM_ALL_PROJECTS}), or \"all\".")
if( LLVM_ENABLE_PROJECTS STREQUAL "all" )
@@ -885,13 +885,16 @@ if( LLVM_INCLUDE_EXAMPLES )
endif()
if( LLVM_INCLUDE_TESTS )
- if(EXISTS ${LLVM_MAIN_SRC_DIR}/projects/test-suite AND TARGET clang)
- include(LLVMExternalProjectUtils)
- llvm_ExternalProject_Add(test-suite
${LLVM_MAIN_SRC_DIR}/projects/test-suite
- USE_TOOLCHAIN
- EXCLUDE_FROM_ALL
- NO_INSTALL
- ALWAYS_CLEAN)
+ if(TARGET clang)
+ if(EXISTS ${LLVM_MAIN_SRC_DIR}/projects/test-suite)
+ include(LLVMExternalProjectUtils)
+ llvm_ExternalProject_Add(test-suite
${LLVM_MAIN_SRC_DIR}/projects/test-suite
+ USE_TOOLCHAIN
+ EXCLUDE_FROM_ALL
+ NO_INSTALL
+ ALWAYS_CLEAN)
+ endif()
+ add_llvm_external_project(debuginfo-tests projects/debuginfo-tests)
endif()
add_subdirectory(utils/lit)
add_subdirectory(test)
diff --git a/projects/CMakeLists.txt b/projects/CMakeLists.txt
index 9102efbdcb4..11835fa89d2 100644
--- a/projects/CMakeLists.txt
+++ b/projects/CMakeLists.txt
@@ -10,6 +10,7 @@ foreach(entry ${entries})
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/libcxxabi) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/libunwind) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/test-suite) AND
+ (NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/debuginfo-tests) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/parallel-libs) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/openmp))
add_subdirectory(${entry})
diff --git a/utils/lit/lit/llvm/config.py b/utils/lit/lit/llvm/config.py
index c631f8b8865..c2e5c9ff141 100644
--- a/utils/lit/lit/llvm/config.py
+++ b/utils/lit/lit/llvm/config.py
@@ -413,8 +413,10 @@ class LLVMConfig(object):
self.config.substitutions.append(
('%target_itanium_abi_host_triple', ''))
- self.config.substitutions.append(
- ('%src_include_dir', self.config.clang_src_dir + '/include'))
+ clang_src_dir = getattr(self.config, 'clang_src_dir', None)
+ if clang_src_dir:
+ self.config.substitutions.append(
+ ('%src_include_dir', os.path.join(clang_src_dir, 'include')))
# FIXME: Find nicer way to prohibit this.
self.config.substitutions.append(
diff --git a/utils/test_debuginfo.pl b/utils/test_debuginfo.pl
deleted file mode 100755
index aaf90d95468..00000000000
--- a/utils/test_debuginfo.pl
+++ /dev/null
@@ -1,80 +0,0 @@
-#!/usr/bin/perl
-#
-# This script tests debugging information generated by a compiler.
-# Input arguments
-# - Input source program. Usually this source file is decorated using
-# special comments to communicate debugger commands.
-# - Executable file. This file is generated by the compiler.
-#
-# This perl script extracts debugger commands from input source program
-# comments in a script. A debugger is used to load the executable file
-# and run the script generated from source program comments. Finally,
-# the debugger output is checked, using FileCheck, to validate
-# debugging information.
-#
-# On Darwin the default is to use the llgdb.py wrapper script which
-# translates gdb commands into their lldb equivalents.
-
-use File::Basename;
-use Config;
-use Cwd;
-
-my $testcase_file = $ARGV[0];
-my $executable_file = $ARGV[1];
-
-my $input_filename = basename $testcase_file;
-my $output_dir = dirname $executable_file;
-
-my $debugger_script_file = "$output_dir/$input_filename.debugger.script";
-my $output_file = "$output_dir/$input_filename.gdb.output";
-
-my %cmd_map = ();
-# Assume lldb to be the debugger on Darwin.
-my $use_lldb = 0;
-$use_lldb = 1 if ($Config{osname} eq "darwin");
-
-# Extract debugger commands from testcase. They are marked with DEBUGGER:
-# at the beginning of a comment line.
-open(INPUT, $testcase_file);
-open(OUTPUT, ">$debugger_script_file");
-while(<INPUT>) {
- my($line) = $_;
- $i = index($line, "DEBUGGER:");
- if ( $i >= 0) {
- $l = length("DEBUGGER:");
- $s = substr($line, $i + $l);
- print OUTPUT "$s";
- }
-}
-print OUTPUT "\n";
-print OUTPUT "quit\n";
-close(INPUT);
-close(OUTPUT);
-
-# setup debugger and debugger options to run a script.
-my $my_debugger = $ENV{'DEBUGGER'};
-if (!$my_debugger) {
- if ($use_lldb) {
- my $path = dirname(Cwd::abs_path($0));
- $my_debugger = "/usr/bin/env python
$path/../tools/clang/test/debuginfo-tests/llgdb.py";
- } else {
- $my_debugger = "gdb";
- }
-}
-
-# quiet / exit after cmdline / no init file / execute script
-my $debugger_options = "-q -batch -n -x";
-
-# run debugger and capture output.
-system("$my_debugger $debugger_options $debugger_script_file
$executable_file > $output_file 2>&1");
-
-# validate output.
-system("FileCheck", "-input-file", "$output_file", "$testcase_file");
-if ($?>>8 == 1) {
- print "Debugger output was:\n";
- system("cat", "$output_file");
- exit 1;
-}
-else {
- exit 0;
-}
On Tue, Nov 21, 2017 at 9:29 PM, Zachary Turner <zturner at google.com> wrote:
> Definitely welcome to look into it, but unless you have physical access to
> one of these buildbots, I don't think we should commit anything else
> speculatively without having someone who does have physical access first
> confirm it.
>
> On Tue, Nov 21, 2017 at 7:25 PM Don Hinton <hintonda at gmail.com> wrote:
>
>> I sorta enjoy debugging stuff like this, so if you don't mind, I'll dig
>> into it once I get a chance -- traveling so, my access is a bit sketchy
>> right now.
>>
>> I'll see if I can grab the logs and let you know if I find anything
>> interesting.
>>
>> On Tue, Nov 21, 2017 at 7:04 PM, Zachary Turner <zturner at google.com>
>> wrote:
>>
>>> That change was added specifically to workaround a failure in a previous
>>> version of the commit. I think as chandler says it's pretty much
>>> impossible for me to make any progress unless someone whose build bot is
>>> failing actually sits down, applies the patch, makes it work, and then
>>> sends me back the result.
>>>
>>> On Tue, Nov 21, 2017 at 7:03 PM Don Hinton <hintonda at gmail.com> wrote:
>>>
>>>> Hi Zackary,
>>>>
>>>> Did you see my followup to you cfe-commits rollback:
>>>>
>>>> http://lists.llvm.org/pipermail/cfe-commits/Week-of-
>>>> Mon-20171120/210212.html
>>>>
>>>> I think you can just remove the change to cfe/trunk/test/CMakeLists.txt
>>>> and it should work just fine.
>>>>
>>>> hth...
>>>> don
>>>>
>>>> On Tue, Nov 21, 2017 at 12:00 PM Zachary Turner via llvm-dev <
>>>> llvm-dev at lists.llvm.org> wrote:
>>>>
>>>>> Just an update,
>>>>>
>>>>> At this point I've submitted and reverted this probably 6+ times, and
>>>>> I don't have time to be blocked by this anymore.
>>>>>
>>>>> I'm looking into alternatives for now, including ways of creating a
>>>>> new top-level git repo such as https://git.llvm.org/git/
>>>>> codeview-tests.git/.
>>>>>
>>>>> I wish there were another way, but at this point I've been working on
>>>>> appeasing this for close to 2 months and I need some control over the bits
>>>>> that determine whether I'm able to make forward progress.
>>>>>
>>>>> If and when someone on the Apple side has some time to make this work
>>>>> with their build infrastructure, I will be happy to revisit.
>>>>>
>>>>> On Mon, Nov 13, 2017 at 4:44 PM Zachary Turner <zturner at google.com>
>>>>> wrote:
>>>>>
>>>>>> Great! It's close to the end of the day, so I'll submit tomorrow to
>>>>>> make sure everything has a chance to go fully green again to ensure I get
>>>>>> failure emails if it breaks.
>>>>>>
>>>>>> On Mon, Nov 13, 2017 at 4:43 PM Adrian Prantl <aprantl at apple.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I can confirm that that fixes the issue!
>>>>>>>
>>>>>>> — adrian
>>>>>>>
>>>>>>>
>>>>>>> On Nov 13, 2017, at 4:38 PM, Zachary Turner <zturner at google.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Yea I also just found it. Try adding this code in the bottom of
>>>>>>> debuginfo-tests/lit.cfg.py
>>>>>>>
>>>>>>> lit.util.usePlatformSdkOnDarwin(config, lit_config)
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Nov 13, 2017 at 4:38 PM Adrian Prantl <aprantl at apple.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Ha! Found it. *Somebody* is setting an SDKROOT variable in the
>>>>>>>> environment. Can you find the code that would do this?
>>>>>>>>
>>>>>>>> — adrian
>>>>>>>>
>>>>>>>> > On Nov 13, 2017, at 4:30 PM, Adrian Prantl via llvm-dev <
>>>>>>>> llvm-dev at lists.llvm.org> wrote:
>>>>>>>> >
>>>>>>>> > Yes I can reproduce this locally. It looks like we are not
>>>>>>>> passing an -isysroot (pointing to the SDK) to clang but it isn’t clear what
>>>>>>>> lit magic would expand this.
>>>>>>>> >
>>>>>>>> > -- adrian
>>>>>>>> >
>>>>>>>> >> On Nov 13, 2017, at 3:30 PM, Zachary Turner <zturner at google.com>
>>>>>>>> wrote:
>>>>>>>> >>
>>>>>>>> >> Yea I'm preparing a revert right now. Does it happen for you
>>>>>>>> when you run debuginfo-tests locally?
>>>>>>>> >>
>>>>>>>> >> On Mon, Nov 13, 2017 at 3:28 PM Adrian Prantl <aprantl at apple.com>
>>>>>>>> wrote:
>>>>>>>> >> Since this is causing all of our internal CI to back up, could
>>>>>>>> you please revert your two changes, so we can make sure that they were
>>>>>>>> actually responsible, and can work on a fix for this? Let me know how we
>>>>>>>> can help investigate this.
>>>>>>>> >>
>>>>>>>> >> -- adrian
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> >>> On Nov 13, 2017, at 3:25 PM, Adrian Prantl via llvm-dev <
>>>>>>>> llvm-dev at lists.llvm.org> wrote:
>>>>>>>> >>>
>>>>>>>> >>> The first build where a test fails with similar symptoms has
>>>>>>>> just one blamelist entry:
>>>>>>>> >>>
>>>>>>>> >>> http://green.lab.llvm.org/green/job/clang-stage1-
>>>>>>>> configure-RA/40391/
>>>>>>>> >>>
>>>>>>>> >>> • Update test_debuginfo.pl script to point to new tree
>>>>>>>> location. (detail/ViewSVN)
>>>>>>>> >>> by zturner
>>>>>>>> >>> -- adrian
>>>>>>>> >>>
>>>>>>>> >>>> On Nov 13, 2017, at 3:21 PM, Zachary Turner <
>>>>>>>> zturner at google.com> wrote:
>>>>>>>> >>>>
>>>>>>>> >>>> On the other hand this file hasn't changed recently, but I
>>>>>>>> have no way to test this as it uses the LLDB code path, which only runs on
>>>>>>>> OSX.
>>>>>>>> >>>>
>>>>>>>> >>>> On Mon, Nov 13, 2017 at 3:19 PM Zachary Turner <
>>>>>>>> zturner at google.com> wrote:
>>>>>>>> >>>> I might be missing something, but this doesn't look like me?
>>>>>>>> >>>>
>>>>>>>> >>>> http://green.lab.llvm.org/green/job/clang-stage1-
>>>>>>>> configure-RA/40478/consoleFull#-42777206a1ca8a51-
>>>>>>>> 895e-46c6-af87-ce24fa4cd561
>>>>>>>> >>>>
>>>>>>>> >>>> PASS: debuginfo-tests :: dbg-arg.c (34886 of 40729)
>>>>>>>> >>>> PASS: debuginfo-tests :: ctor.cpp (34887 of 40729)
>>>>>>>> >>>> PASS: debuginfo-tests :: ctor.cpp (34888 of 40729)
>>>>>>>> >>>> PASS: debuginfo-tests :: aggregate-indirect-arg.cpp (34889 of
>>>>>>>> 40729)
>>>>>>>> >>>> PASS: debuginfo-tests :: aggregate-indirect-arg.cpp (34890 of
>>>>>>>> 40729)
>>>>>>>> >>>> PASS: debuginfo-tests :: dbg-arg.c (34891 of 40729)
>>>>>>>> >>>> PASS: debuginfo-tests :: asan.c (34892 of 40729)
>>>>>>>> >>>> PASS: debuginfo-tests :: asan.c (34893 of 40729)
>>>>>>>> >>>> PASS: debuginfo-tests :: asan-blocks.c (34894 of 40729)
>>>>>>>> >>>> PASS: debuginfo-tests :: asan-blocks.c (34895 of 40729)
>>>>>>>> >>>> PASS: debuginfo-tests :: nested-struct.cpp (34896 of 40729)
>>>>>>>> >>>> PASS: debuginfo-tests :: nested-struct.cpp (34897 of 40729)
>>>>>>>> >>>> PASS: debuginfo-tests :: forward-declare-class.cpp (34898 of
>>>>>>>> 40729)
>>>>>>>> >>>> PASS: debuginfo-tests :: forward-declare-class.cpp (34899 of
>>>>>>>> 40729)
>>>>>>>> >>>> FAIL: debuginfo-tests :: foreach.m (34900 of 40729)
>>>>>>>> >>>>
>>>>>>>> >>>> ******************** TEST 'debuginfo-tests :: foreach.m'
>>>>>>>> FAILED ********************
>>>>>>>> >>>>
>>>>>>>> >>>> Script:
>>>>>>>> >>>> --
>>>>>>>> >>>> /Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>> configure-RA/clang-build/bin/clang --target=x86_64-apple-darwin15.6.0
>>>>>>>> -O0 -g /Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>> configure-RA/llvm/tools/clang/test/debuginfo-tests/tests/foreach.m
>>>>>>>> -c -o /Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>> configure-RA/clang-build/tools/clang/test/debuginfo-
>>>>>>>> tests/Output/foreach.m.tmp.o
>>>>>>>> >>>> /Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>> configure-RA/clang-build/bin/clang --target=x86_64-apple-darwin15.6.0
>>>>>>>> /Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>> configure-RA/clang-build/tools/clang/test/debuginfo-tests/Output/foreach.m.tmp.o
>>>>>>>> -o /Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>> configure-RA/clang-build/tools/clang/test/debuginfo-tests/Output/foreach.m.tmp.out
>>>>>>>> -framework Foundation
>>>>>>>> >>>> /Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>> configure-RA/llvm/utils/
>>>>>>>> >>>> test_debuginfo.pl
>>>>>>>> >>>> /Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>> configure-RA/llvm/tools/clang/test/debuginfo-tests/tests/foreach.m
>>>>>>>> /Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>> configure-RA/clang-build/tools/clang/test/debuginfo-
>>>>>>>> tests/Output/foreach.m.tmp.out
>>>>>>>> >>>> --
>>>>>>>> >>>> Exit Code: 1
>>>>>>>> >>>>
>>>>>>>> >>>> Command Output (stdout):
>>>>>>>> >>>> --
>>>>>>>> >>>> Debugger output was:
>>>>>>>> >>>> imported lldb from: "/Applications/Xcode.app/
>>>>>>>> Contents/SharedFrameworks/LLDB.framework/Versions/A/
>>>>>>>> Resources/Python"
>>>>>>>> >>>> error: foreach.m.tmp.out debug map object file
>>>>>>>> '/Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>> configure-RA/clang-build/tools/clang/test/debuginfo-tests/Output/foreach.m.tmp.o'
>>>>>>>> has changed (actual time is 0x5a0a2528, debug map time is 0x5a0a2526) since
>>>>>>>> this executable was linked, file will be ignored
>>>>>>>> >>>> > break 25
>>>>>>>> >>>> SBBreakpoint: id = 1, file = '', line = 25, exact_match = 0,
>>>>>>>> locations = 0
>>>>>>>> >>>> > r
>>>>>>>> >>>> success
>>>>>>>> >>>> > po thing
>>>>>>>> >>>> = <could not resolve type>
>>>>>>>> >>>> > quit
>>>>>>>> >>>>
>>>>>>>> >>>> --
>>>>>>>> >>>> Command Output (stderr):
>>>>>>>> >>>> --
>>>>>>>> >>>>
>>>>>>>> >>>> /Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>> configure-RA/llvm/tools/clang/test/debuginfo-tests/tests/foreach.m:11:11:
>>>>>>>> error: expected string not found in input
>>>>>>>> >>>>
>>>>>>>> >>>> // CHECK: aaa
>>>>>>>> >>>> ^
>>>>>>>> >>>> /Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>> configure-RA/clang-build/tools/clang/test/debuginfo-
>>>>>>>> tests/Output/foreach.m.gdb.output:1:1: note: scanning from here
>>>>>>>> >>>> imported lldb from: "/Applications/Xcode.app/
>>>>>>>> Contents/SharedFrameworks/LLDB.framework/Versions/A/
>>>>>>>> Resources/Python"
>>>>>>>> >>>> ^
>>>>>>>> >>>> /Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>> configure-RA/clang-build/tools/clang/test/debuginfo-
>>>>>>>> tests/Output/foreach.m.gdb.output:2:211: note: possible intended
>>>>>>>> match here
>>>>>>>> >>>> error: foreach.m.tmp.out debug map object file
>>>>>>>> '/Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>> configure-RA/clang-build/tools/clang/test/debuginfo-tests/Output/foreach.m.tmp.o'
>>>>>>>> has changed (actual time is 0x5a0a2528, debug map time is 0x5a0a2526) since
>>>>>>>> this executable was linked, file will be ignored
>>>>>>>> >>>>
>>>>>>>> >>>>
>>>>>>>> >>>>
>>>>>>>> >>>> On Mon, Nov 13, 2017 at 3:17 PM Adrian Prantl <
>>>>>>>> aprantl at apple.com> wrote:
>>>>>>>> >>>> It looks like the bots are still red?
>>>>>>>> >>>>
>>>>>>>> >>>> — Adrian
>>>>>>>> >>>>
>>>>>>>> >>>>
>>>>>>>> >>>>> On Nov 10, 2017, at 3:14 PM, Zachary Turner <
>>>>>>>> zturner at google.com> wrote:
>>>>>>>> >>>>>
>>>>>>>> >>>>> Wasn't quite fixed, but it got a lot further this time. This
>>>>>>>> time there was still an issue in the test_debuginfo.pl script
>>>>>>>> regarding a hardcoded path to the llgdb.py script. I think I never
>>>>>>>> encountered this locally because this codepath only happens on Darwin, and
>>>>>>>> I was testing on Linux.
>>>>>>>> >>>>>
>>>>>>>> >>>>> (As an aside, ugh... Perl...)
>>>>>>>> >>>>>
>>>>>>>> >>>>> Regardless, this should be fixed in r317949, and hopefully
>>>>>>>> that's the last of the issues. I have to run for a couple of hours, but I
>>>>>>>> can check on this again in a bit. But I strongly suspect it will be fixed
>>>>>>>> now.
>>>>>>>> >>>>>
>>>>>>>> >>>>> On Fri, Nov 10, 2017 at 2:51 PM Adrian Prantl <
>>>>>>>> aprantl at apple.com> wrote:
>>>>>>>> >>>>>
>>>>>>>> >>>>>> On Nov 10, 2017, at 2:50 PM, Zachary Turner <
>>>>>>>> zturner at google.com> wrote:
>>>>>>>> >>>>>>
>>>>>>>> >>>>>> I checked in a fix for that already, sorry for the trouble.
>>>>>>>> I’m waiting for it to cycle
>>>>>>>> >>>>>
>>>>>>>> >>>>> awesome. Thanks!
>>>>>>>> >>>>>
>>>>>>>> >>>>> -- adrian
>>>>>>>> >>>>>
>>>>>>>> >>>>>> On Fri, Nov 10, 2017 at 2:49 PM Adrian Prantl <
>>>>>>>> aprantl at apple.com> wrote:
>>>>>>>> >>>>>> It looks like this broke green dragon:
>>>>>>>> >>>>>>
>>>>>>>> >>>>>> http://green.lab.llvm.org/green/job/clang-stage1-
>>>>>>>> configure-RA/40383/console
>>>>>>>> >>>>>>
>>>>>>>> >>>>>> llvm-lit: /Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>> configure-RA/llvm/projects/libcxx/utils/libcxx/test/config.py:173:
>>>>>>>> note: Adding environment variables: {'DYLD_LIBRARY_PATH':
>>>>>>>> '/Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>> configure-RA/clang-build/./lib', 'LIBCXX_FILESYSTEM_DYNAMIC_TEST_ROOT':
>>>>>>>> '/Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>> configure-RA/clang-build/projects/libcxx/test/
>>>>>>>> filesystem/Output/dynamic_env'}
>>>>>>>> >>>>>>
>>>>>>>> >>>>>> llvm-lit: /Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>> configure-RA/llvm/utils/lit/lit/llvm/config.py:332: note: using
>>>>>>>> clang: /Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>> configure-RA/clang-build/bin/clang
>>>>>>>> >>>>>> llvm-lit: /Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>> configure-RA/llvm/utils/lit/lit/util.py:379: note: using SDKROOT:
>>>>>>>> '/Applications/Xcode.app/Contents/Developer/Platforms/
>>>>>>>> MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk'
>>>>>>>> >>>>>>
>>>>>>>> >>>>>> llvm-lit: /Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>> configure-RA/llvm/utils/lit/lit/TestingConfig.py:101: fatal:
>>>>>>>> unable to parse config file '/Users/buildslave/jenkins/
>>>>>>>> workspace/clang-stage1-configure-RA/llvm/tools/clang/
>>>>>>>> test/debuginfo-tests/lit.cfg.py', traceback: Traceback (most
>>>>>>>> recent call last):
>>>>>>>> >>>>>> File "/Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>> configure-RA/llvm/utils/lit/lit/TestingConfig.py", line 88, in
>>>>>>>> load_from_path
>>>>>>>> >>>>>> exec(compile(data, path, 'exec'), cfg_globals, None)
>>>>>>>> >>>>>> File "/Users/buildslave/jenkins/workspace/clang-stage1-
>>>>>>>> configure-RA/llvm/tools/clang/test/debuginfo-tests/lit.cfg.py",
>>>>>>>> line 36, in <module>
>>>>>>>> >>>>>> config.test_source_root = os.path.join(config.debuginfo_tests_src_root,
>>>>>>>> 'tests')
>>>>>>>> >>>>>> AttributeError: TestingConfig instance has no attribute
>>>>>>>> 'debuginfo_tests_src_root'
>>>>>>>> >>>>>>
>>>>>>>> >>>>>> FAILED: CMakeFiles/check-all
>>>>>>>> >>>>>>
>>>>>>>> >>>>>> -- adrian
>>>>>>>> >>>>>>
>>>>>>>> >>>>>> > On Nov 10, 2017, at 1:00 PM, Zachary Turner via llvm-dev <
>>>>>>>> llvm-dev at lists.llvm.org> wrote:
>>>>>>>> >>>>>> >
>>>>>>>> >>>>>> > This is in as of r317925. I'm keeping an eye out for
>>>>>>>> failure notifications. I may or may not need help diagnosing if something
>>>>>>>> does go wrong (although I'm keeping my fingers crossed)
>>>>>>>> >>>>>> >
>>>>>>>> >>>>>> > On Thu, Nov 9, 2017 at 4:05 PM Zachary Turner <
>>>>>>>> zturner at google.com> wrote:
>>>>>>>> >>>>>> > Since it's towards the end of the day already, I'll put
>>>>>>>> this in tomorrow morning around 9 or 10, to make sure I'm around to fix
>>>>>>>> anything that arises (or revert).
>>>>>>>> >>>>>> >
>>>>>>>> >>>>>> >
>>>>>>>> >>>>>> >
>>>>>>>> >>>>>> > On Thu, Nov 9, 2017 at 2:53 PM Mike Edwards <
>>>>>>>> medwards at apple.com> wrote:
>>>>>>>> >>>>>> > Hi Zach,
>>>>>>>> >>>>>> > Thanks for doing this extra work to make this lower impact
>>>>>>>> for the rest of us. Let’s give it a try and see what happens.
>>>>>>>> >>>>>> >
>>>>>>>> >>>>>> > -Mike
>>>>>>>> >>>>>> >
>>>>>>>> >>>>>> >
>>>>>>>> >>>>>> >
>>>>>>>> >>>>>> >> On Nov 9, 2017, at 13:37, Zachary Turner <
>>>>>>>> zturner at google.com> wrote:
>>>>>>>> >>>>>> >>
>>>>>>>> >>>>>> >> Hi all, I think I've addressed all the concerns here, and
>>>>>>>> I believe there should be no immediate impact to the current workflow.
>>>>>>>> with that said, I plan to commit this either later today or early tomorrow
>>>>>>>> if there are no other concerns.
>>>>>>>> >>>>>> >>
>>>>>>>> >>>>>> >> On Tue, Nov 7, 2017 at 12:19 PM Zachary Turner <
>>>>>>>> zturner at google.com> wrote:
>>>>>>>> >>>>>> >> I tested this out, and AFAICT nothing will change. It
>>>>>>>> will continue to just work if you have it checked out under clang/tests.
>>>>>>>> It's a bit hard to construct this configuration locally since it requires
>>>>>>>> moving some files around, and applying half of a CL here and half of a CL
>>>>>>>> there. But, AFAICT it works.
>>>>>>>> >>>>>> >>
>>>>>>>> >>>>>> >> I'm happy to send you some patches if you want to try
>>>>>>>> them locally and confirm.
>>>>>>>> >>>>>> >>
>>>>>>>> >>>>>> >> I'd like to print out a CMake warning if it detects the
>>>>>>>> tree under clang/test and just mention that the workflow is deprecated.
>>>>>>>> Any objections?
>>>>>>>> >>>>>> >>
>>>>>>>> >>>>>> >> On Mon, Nov 6, 2017 at 1:49 PM Mike Edwards <
>>>>>>>> medwards at apple.com> wrote:
>>>>>>>> >>>>>> >> Thank you Zach.
>>>>>>>> >>>>>> >>
>>>>>>>> >>>>>> >>
>>>>>>>> >>>>>> >>> On Nov 6, 2017, at 13:37, Zachary Turner <
>>>>>>>> zturner at google.com> wrote:
>>>>>>>> >>>>>> >>>
>>>>>>>> >>>>>> >>> I’m going to spend a little time seeing if i can make
>>>>>>>> the change invisible to the bots so they will continue to work as they do
>>>>>>>> today. Will report back after I’ve explored that a bit
>>>>>>>> >>>>>> >>> On Mon, Nov 6, 2017 at 1:35 PM Mike Edwards <
>>>>>>>> medwards at apple.com> wrote:
>>>>>>>> >>>>>> >>>> I'm honestly not opposed to this idea. It just seems a
>>>>>>>> shame to do this for purely logistical reasons if most people agree that
>>>>>>>> the "right" place for debuginfo-tests is outside of the clang tree.
>>>>>>>> >>>>>> >>>
>>>>>>>> >>>>>> >>> I totally understand what you are saying here and will
>>>>>>>> just add that sometimes being part of a larger community means being
>>>>>>>> willing to do things, sometimes, not exactly the “right” way, due to
>>>>>>>> logistical reasons. I am not opposed to what you would like to do, I’m
>>>>>>>> just furrowing my brow at the timeframe in which to do it.
>>>>>>>> >>>>>> >>>
>>>>>>>> >>>>>> >>>>
>>>>>>>> >>>>>> >>>> That said, I'd still like to hear from ChrisM and MikeE
>>>>>>>> about why it will take so long, because on the surface it seems like a
>>>>>>>> low-impact move.
>>>>>>>> >>>>>> >>>
>>>>>>>> >>>>>> >>> Past experience has taught me, anything I think is going
>>>>>>>> to be simple and quick to fix, rarely ever turns out that way. While there
>>>>>>>> will be a significant amount of work to change the way our bots work here
>>>>>>>> at Apple, the work is not impossible to accomplish. Given the choice, I
>>>>>>>> would of course prefer an approach such as Paulr has suggested. The
>>>>>>>> ability to run things in parallel for a time provides for a much lower
>>>>>>>> impact change on the entire community. I think this approach may also give
>>>>>>>> us some time to decide where the debuginfo-test should fit in the new
>>>>>>>> mono-repo. It would be a bummer to do the work necessary to make this
>>>>>>>> change, only to discover we would have to do it differently in the not too
>>>>>>>> distant future to accommodate the new mono-repo.
>>>>>>>> >>>>>> >>>
>>>>>>>> >>>>>> >>> Zach, I do not want to be a blocker here. I just want
>>>>>>>> to make sure we have explored all of the options to make sure we are not
>>>>>>>> missing a lower impact approach. I also want to make sure we are not doing
>>>>>>>> something that could wait until we migrate to the mono-repo next year.
>>>>>>>> >>>>>> >>>
>>>>>>>> >>>>>> >>> Thanks,
>>>>>>>> >>>>>> >>> Mike
>>>>>>>> >>>>>> >>
>>>>>>>> >>>>>> >
>>>>>>>> >>>>>> > _______________________________________________
>>>>>>>> >>>>>> > LLVM Developers mailing list
>>>>>>>> >>>>>> > llvm-dev at lists.llvm.org
>>>>>>>> >>>>>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>>>>> >>>>>>
>>>>>>>> >>>>>
>>>>>>>> >>>>
>>>>>>>> >>>
>>>>>>>> >>> _______________________________________________
>>>>>>>> >>> LLVM Developers mailing list
>>>>>>>> >>> llvm-dev at lists.llvm.org
>>>>>>>> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>>>>> >>
>>>>>>>> >
>>>>>>>> > _______________________________________________
>>>>>>>> > LLVM Developers mailing list
>>>>>>>> > llvm-dev at lists.llvm.org
>>>>>>>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> llvm-dev at lists.llvm.org
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>>
>>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171125/3d58ce03/attachment.html>
More information about the llvm-dev
mailing list