Don Hinton via llvm-dev
2017-Nov-22 03:25 UTC
[llvm-dev] PSA: debuginfo-tests workflow changing slightly
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: >> >> 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 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: >>>>>> >>> >>>>>> >>> 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? >>>>>> >>>> >>>>>> >>>> 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: >>>>>> >>>>>> >>>>>> >>>>>> 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 >>>>>> >>>>>> > lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>>>> >>>>>> >>>>>> >>>>> >>>>>> >>>> >>>>>> >>> >>>>>> >>> _______________________________________________ >>>>>> >>> LLVM Developers mailing list >>>>>> >>> llvm-dev at lists.llvm.org >>>>>> >>> lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>>>> >> >>>>>> > >>>>>> > _______________________________________________ >>>>>> > LLVM Developers mailing list >>>>>> > llvm-dev at lists.llvm.org >>>>>> > lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>>>> >>>>>> >>>>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >>-------------- next part -------------- An HTML attachment was scrubbed... URL: <lists.llvm.org/pipermail/llvm-dev/attachments/20171121/6a3dfe41/attachment.html>
Zachary Turner via llvm-dev
2017-Nov-22 05:29 UTC
[llvm-dev] PSA: debuginfo-tests workflow changing slightly
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: >>> >>> >>> 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 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: >>>>>>> >>> >>>>>>> >>> >>>>>>> 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? >>>>>>> >>>> >>>>>>> >>>> >>>>>>> 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: >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> 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 >>>>>>> >>>>>> > lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>>>>> >>>>>> >>>>>>> >>>>> >>>>>>> >>>> >>>>>>> >>> >>>>>>> >>> _______________________________________________ >>>>>>> >>> LLVM Developers mailing list >>>>>>> >>> llvm-dev at lists.llvm.org >>>>>>> >>> lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>>>>> >> >>>>>>> > >>>>>>> > _______________________________________________ >>>>>>> > LLVM Developers mailing list >>>>>>> > llvm-dev at lists.llvm.org >>>>>>> > lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> llvm-dev at lists.llvm.org >>>> lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> >>> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <lists.llvm.org/pipermail/llvm-dev/attachments/20171122/59540d4d/attachment-0001.html>
Don Hinton via llvm-dev
2017-Nov-25 23:46 UTC
[llvm-dev] PSA: debuginfo-tests workflow changing slightly
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: >>>> >>>> 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 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: >>>>>>>> >>> >>>>>>>> >>> 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? >>>>>>>> >>>> >>>>>>>> >>>> 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: >>>>>>>> >>>>>> >>>>>>>> >>>>>> 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 >>>>>>>> >>>>>> > lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>>>>>> >>>>>> >>>>>>>> >>>>> >>>>>>>> >>>> >>>>>>>> >>> >>>>>>>> >>> _______________________________________________ >>>>>>>> >>> LLVM Developers mailing list >>>>>>>> >>> llvm-dev at lists.llvm.org >>>>>>>> >>> lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>>>>>> >> >>>>>>>> > >>>>>>>> > _______________________________________________ >>>>>>>> > LLVM Developers mailing list >>>>>>>> > llvm-dev at lists.llvm.org >>>>>>>> > lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>> LLVM Developers mailing list >>>>> llvm-dev at lists.llvm.org >>>>> lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>>> >>>> >>-------------- next part -------------- An HTML attachment was scrubbed... URL: <lists.llvm.org/pipermail/llvm-dev/attachments/20171125/3d58ce03/attachment.html>