Page MenuHomePhabricator

[lldb][test_suite] change the test main.cpp to avoid expression reschedule
AcceptedPublic

Authored by kusmour on Jul 15 2019, 1:51 PM.

Details

Reviewers
xiaobai
labath
Summary

Added a local variable to hold the return value to avoid delayed calculation on variables
This issue occurred when using NDK 20 clang with -O0 flag set

Diff Detail

Repository
rLLDB LLDB

Event Timeline

kusmour created this revision.Jul 15 2019, 1:51 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 15 2019, 1:51 PM
labath accepted this revision.Jul 16 2019, 4:24 AM

The change is fine, but for my own education, could you elaborate on what this "delayed calculation" is, and how does it make the test fail?

This revision is now accepted and ready to land.Jul 16 2019, 4:24 AM

The change is fine, but for my own education, could you elaborate on what this "delayed calculation" is, and how does it make the test fail?

The test set the breakpoint to the return statement, even thought the compiler flag -O0 was set, the first hit to that bp showed that g_common_1 = 0 which actually should be 21. The test assume when we hit the return statement, the value should already be calculated, but that's not the case for NDK20 clang.

So we reproduce the test manually, turned out that the value was calculated later. lldb first hit the return statement then jump back to line 20. By looking at the assembly that clang provided, it indeed jump back and forth.

It's possible that the jumping behavior is caused by optimization, considering there're some other tests having similar problem, and the behavior changed a lot from NDK 19 to 20. I made this change because this is irrelevant to testing global variables.

The test set the breakpoint to the return statement, even thought the compiler flag -O0 was set, the first hit to that bp showed that g_common_1 = 0 which actually should be 21. The test assume when we hit the return statement, the value should already be calculated, but that's not the case for NDK20 clang.

So we reproduce the test manually, turned out that the value was calculated later. lldb first hit the return statement then jump back to line 20. By looking at the assembly that clang provided, it indeed jump back and forth.

It's possible that the jumping behavior is caused by optimization, considering there're some other tests having similar problem, and the behavior changed a lot from NDK 19 to 20. I made this change because this is irrelevant to testing global variables.

Yeah, this problem isn't a bug in the debugger, but it could be considered a bug in the compiler, as one wouldn't expect the line numbers to jump around like this at -O0. And indeed, if we compare the the ndk r20 clang output with the current ToT, then we can see that they generate nearly identical assembly, but their line numbers differ. So it looks like somebody did consider this to be a bug and fixed it already.

Anyway, working around that here seems fine...

davide added a subscriber: davide.Jul 17 2019, 8:27 AM

That real

The change is fine, but for my own education, could you elaborate on what this "delayed calculation" is, and how does it make the test fail?

The test set the breakpoint to the return statement, even thought the compiler flag -O0 was set, the first hit to that bp showed that g_common_1 = 0 which actually should be 21. The test assume when we hit the return statement, the value should already be calculated, but that's not the case for NDK20 clang.

So we reproduce the test manually, turned out that the value was calculated later. lldb first hit the return statement then jump back to line 20. By looking at the assembly that clang provided, it indeed jump back and forth.

It's possible that the jumping behavior is caused by optimization, considering there're some other tests having similar problem, and the behavior changed a lot from NDK 19 to 20. I made this change because this is irrelevant to testing global variables.

that really sounds like a DebugInfo problem. Can you reproduce on ToT?