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

[polyakov.alex]

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.

[polyakov.alex]

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

[stella.stamenova]

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]

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?

[polyakov.alex]

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

[polyakov.alex]

In D47679#1120039, @stella.stamenova wrote:

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.

[aprantl]

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

0–1

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

[aprantl]

lit/tools/lldb-mi/breakpoint/break-insert.test

0–1

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

[stella.stamenova]

In D47679#1120081, @polyakov.alex wrote:

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.

In D47679#1120166, @aprantl wrote:

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

0–1

It will still fail and it will still hang.

[polyakov.alex]

In D47679#1120172, @stella.stamenova wrote:

In D47679#1120081, @polyakov.alex wrote:

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.

[stella.stamenova]

In D47679#1120177, @polyakov.alex wrote:

In D47679#1120172, @stella.stamenova wrote:

In D47679#1120081, @polyakov.alex wrote:

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.

[polyakov.alex]

Thank you.

[stella.stamenova]

I stand corrected. The test didn't hang.

lit/tools/lldb-mi/breakpoint/break-insert.test

-# REQUIRES: nowindows
-# -> llvm.org/pr24452
-# Rather than XFAILing the test, skip it on Windows because it hangs
-
-# RUN: %cc %p/inputs/break-insert.c -g
+# RUN: %cc -o a.exe %p/inputs/break-insert.c -g
 # RUN: %lldbmi < %s | FileCheck %s
 
 # Test that a breakpoint can be inserted before creating a target.
 
 -break-insert breakpoint
 # CHECK: ^done,bkpt={number="1"
 
--file-exec-and-symbols a.out
+-file-exec-and-symbols a.exe
 # CHECK: ^done
 
 -exec-run
 # CHECK: ^running
 # CHECK: *stopped,reason="breakpoint-hit"