Page MenuHomePhabricator

[lldb, lldb-mi] Enable lldb-mi -break-insert test on Windows.
ClosedPublic

Authored by polyakov.alex on Jun 2 2018, 3:41 PM.

Details

Summary

The default name for a compiler output on Linux is a.out, while on Windows it's a.exe. But if we add option -o a.exe, the compiler will create the executable a.exe on the both systems.

Diff Detail

Repository
rL LLVM

Event Timeline

polyakov.alex created this revision.Jun 2 2018, 3:41 PM

I would really appreciate if you guys can check this test on Windows again.

stella.stamenova added a comment.EditedJun 2 2018, 3:51 PM

You can actually follow the pattern in the other tests and do:

%cc -o %t %p/inputs/break-insert.c -g

%t then becomes the name of the output file and you can use that in our other commands. This is better than specifying a hardcoded name.

Having said that, I believe this won't fix the test. If you look at the comments of the review when I disabled the test, there is output of what happens when you give it the correct name - which is to run until the program exits *normally* rather than hitting a breakpoint as the test expects. After the program exits normally, lldb-mi just waits and the test will hang. Your other change will address the issue of the test hanging when it's given the incorrect file name, but I don't think it will fix this case.

polyakov.alex added a comment.EditedJun 2 2018, 4:00 PM

You are right. I think that the reason of exiting *normally is much deeper. I'll look at this, but for now I don't have any idea about what this may be caused by, do you have one?

Due to https://reviews.llvm.org/D47678 we can enable this test with a XFAIL directive for Windows.

You can actually follow the pattern in the other tests and do:

%cc -o %t %p/inputs/break-insert.c -g

%t then becomes the name of the output file and you can use that in our other commands. This is better than specifying a hardcoded name.

We can't use it here since lldb-mi reads %s file with input, then %t won't be changed to any path, so debugger will try to find executable with name %t and fail.

Stella, is there a public bot that runs the tests on Windows that we could watch? I found http://lab.llvm.org:8011/builders/lldb-x86-windows-msvc2015?numbuilds=1000 but it doesn't look like that one actually failed with the error you saw.

lit/tools/lldb-mi/breakpoint/break-insert.test
1 ↗(On Diff #149629)

Do we still expect the test to fail after this change?

aprantl added inline comments.Jun 3 2018, 7:52 AM
lit/tools/lldb-mi/breakpoint/break-insert.test
1 ↗(On Diff #149629)

Nevermind.. phabricator folded your entire conversation away. This is about lldb-mi hanging after the program exit.

stella.stamenova added a comment.EditedJun 3 2018, 7:57 AM

Due to https://reviews.llvm.org/D47678 we can enable this test with a XFAIL directive for Windows.

Not true. As I said, the original review when I disabled the test has the log of what happens when you give it the correct path and the test still hangs in that scenario. If you XFAIL it, it will hang.

Stella, is there a public bot that runs the tests on Windows that we could watch? I found http://lab.llvm.org:8011/builders/lldb-x86-windows-msvc2015?numbuilds=1000 but it doesn't look like that one actually failed with the error you saw.

@aprantl There is currently no public bot that runs the tests. The one you found just builds but runs no tests. I have a machine I am going to add as a bot but there are still a lot of failing tests, so I don’t want to add it yet as it will be just noise until the tests are fixed or disabled.

lit/tools/lldb-mi/breakpoint/break-insert.test
1 ↗(On Diff #149629)

It will still fail and it will still hang.

Due to https://reviews.llvm.org/D47678 we can enable this test with a XFAIL directive for Windows.

Not true. As I said, the original review when I disabled the test has the log of what happens when you give it the correct path and the test still hangs in that scenario. If you XFAIL it, it will hang.

Yep, I got the same on Linux. But if you run it through llvm-lit(not lldb-mi < input-file) it won't hang.

Due to https://reviews.llvm.org/D47678 we can enable this test with a XFAIL directive for Windows.

Not true. As I said, the original review when I disabled the test has the log of what happens when you give it the correct path and the test still hangs in that scenario. If you XFAIL it, it will hang.

Yep, I got the same on Linux. But if you run it through llvm-lit(not lldb-mi < input-file) it won't hang.

I can apply your change locally on Monday and double-check. You have to remember that the behavior of the tools and test suite is not exactly the same on Linux and Windows.

stella.stamenova accepted this revision.Jun 4 2018, 11:10 AM

I stand corrected. The test didn't hang.

This revision is now accepted and ready to land.Jun 4 2018, 11:10 AM
This revision was automatically updated to reflect the committed changes.