thr3ads.net - llvm dev - [llvm-dev] PSA: debuginfo-tests workflow changing slightly [Nov 2017]

If this information is useful, please help other people find it:
Share via:

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:
>>
>>   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/20171121/6a3dfe41/attachment.html>

Zachary Turner via llvm-dev

2017-Nov-22 05:29 UTC

head link

[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:
>>>
>>>
>>>
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/20171122/59540d4d/attachment-0001.html>

Don Hinton via llvm-dev

2017-Nov-25 23:46 UTC

head link

[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:
>>>>
>>>>   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>

Reasonably Related Threads

Search for more possibly parallel threads

llvm dev - Nov 2017 - PSA: debuginfo-tests workflow changing slightly

[llvm-dev] PSA: debuginfo-tests workflow changing slightly

[llvm-dev] PSA: debuginfo-tests workflow changing slightly

[llvm-dev] PSA: debuginfo-tests workflow changing slightly

Reasonably Related Threads