[TESTS] Fix TestInlineStepping with ccac compiler

[vasilyev]

Summary

The tests expect the debugger steps into the function, not the string constructor. But that depends on the compiler. Thus, with "ссaс" the tests are failing.

[teemperor]

Thanks for the patch!

A few general notes:

• You probably want to upload the diffs with more context (git diff -U9999 or something like that) to get rid of the "Context not available" in the source changes part. That's sadly how Phabricator works. If you use arcanist to upload patches then I believe it does that automatically for you.
• Please don't add unrelated projects such as "LLDB test suite on simulator" (those are like tags that are used to group reviews that are all related to a specific task/goal). "LLDB" is the right project for general LLDB patches ("LLVM" for patches that target the general LLVM part in llvm/).

Regarding the patch itself: From what I understand what this test (maybe unintentionally) tests it that when we do step-in we apply the target.process.thread.step-avoid-regexp setting (which will skip all std::* functions when doing a step-in from what I know). So It's not clear how to me how LLDB ends up stepping into the std::string constructor (even if ccac is using a custom standard library). Can you post some more details about the test failure you're setting (e.g., where you end up with the source breakpoint and where the step-in actually takes you).

I think this is in any case something for Jim to review.

[jingham]

Raphael is right. The default values of the target.process.thread.step-avoid-regexp are set such that if lldb finds itself in a function inlined from std:: it will automatically step back out. This test is testing that (among other things). The fact that the test is failing means that something in how your compiler is generating symbols or debug info is defeating this. Maybe it's emitting the std:: symbols in such a way that the regexp isn't matching them? Maybe the inline records in the DWARF are confusing lldb somehow?

In any case, changing the test is not the right resolution, if you are stopping in a std::string constructor that is a real failure.

Our test runner allows you to x-fail a test based on compiler and compiler version. In fact this test is x-failed for icc because of some other optimizations that compiler does. So if you're trying to get a clean run it would be fine to file a bug about this failure, then add an expectedFailureAll(compiler="ccac", bugnumber="<BUG_NUMBER>") to the test, and come back and fix the behavior when you or somebody else working on this compiler gets around to it. Or of course, figure out why the behavior is incorrect with the ccac output, and fix that, if you have the time for that now.

[vasilyev]

Thanks for the comments! You are right, this is indeed fixed by https://github.com/llvm/llvm-project/commit/352f16db87f583ec7f55f8028647b5fd8616111f

[teemperor]

So from what I understand this is resolved? If yes, can you abandon/close this revision (You can do this by selecting the "Abandon revision" action above the input field where you can comment).

[vasilyev]

Resolved

lldb/test/API/functionalities/inline-stepping/calling.cpp

     
     function_to_call (); // Make sure debug info for this function gets generated.
     
-    max_value(123, 456);                                // Call max_value template
-    max_value(std::string("abc"), std::string("0022")); // Call max_value specialized
+    max_value(123, 456); // Call max_value template
+
+    std::string s1 = "aba";
+    std::string s2 = "0022";
+
+    max_value(s1, s2);  // Call max_value specialized
 
     return 0;            // About to return from main.
 }