Fix some tests for PPC64le architecture

[lbianc]

Summary

• Fix test jump for powerpc64le Jumping directly to the return line on power architecture dos not means returning the value that is seen on the code. The last test fails, because it needs the execution of some assembly in the beginning of the function. Avoiding this test for this architecture.

• Avoid evaluate environ variable name on Linux On Linux the Symbol environ conflicts with another variable, then in order to avoid it, this test was moved into a specific test, which is not supported if the OS is Linux.

• Added PPC64le as MIPS behavior Checking the disassembler output, on PPC64le machines behaves as MPIS. Added method to identify PPC64le architecture and checking it when disassembling instructions in the test case.

[labath]

The __environ trick may work on other *linux* architectures, but it does not work everywhere (I've just checked mac). I bet the other conflicting symbol you see is in the dynamic loader (you can check with "image lookup -s environ"). The failure is not ppc-specific -- it fails on all linux machines which have a symbol table for the dynamc linker. This is fixable by teaching lldb about the dynamic loader module on linux, which will cause it to not look for symbols there by default (because the normal symbol lookup within the inferior will not look there either). This is why this test passes on mac, but implementing this for linux is not as simple as mac -- there we just check the file header, but on linux there is nothing about the file itself that would tell us that this is really a dynamic linker (at least i haven't found anything). The best solution I could think of for this is to look for AT_BASE in the auxiliary vector, which should point at the dynamic linker, but I haven't gotten around to that yet, as it requires setting up some plumbing. If you don't feel like doing that yourself, I suggest we just move that check into a separate test, and mark it as @skipIfLinux.

The other part that's not clear to me is why you needed to do the function pointer trick in the lldb-mi test. I understand it was needed for lldb-server because it does not know anything about debug info, but it's not clear to me why would this apply to lldb-mi...

packages/Python/lldbsuite/test/tools/lldb-mi/data/TestMiData.py

82–83

The comment should be updated as well. Or, you could make this self documenting and write something like:

has_stub_name = not self.isMIPS() and not self.isPPC64le()
if has_stub_name: ...

[lbianc]

About the environ symbol issue, I'm going to move to a separate test method in the same test file, is it ok?

The function pointer trick is necessary for power architecture, because it has a global entry point, which is not executed when calling the function locally (i. e. in the sabe context). There is a discussion about it here https://reviews.llvm.org/D43768?id=135917.
In this test case, the option skip-prologue is turned off before creating the breakpoint to that function, so consider the function:

<ns::foo1()>    lis     r2,4098
<ns::foo1()+4>  addi    r2,r2,32512
<ns::foo1()+8>  mflr    r0
<ns::foo1()+12> std     r31,-8(r1)
<ns::foo1()+16> std     r0,16(r1)
<ns::foo1()+20> stdu    r1,-112(r1)
<ns::foo1()+24> mr      r31,r1
<ns::foo1()+28> addis   r3,r2,-2
<ns::foo1()+32> addi    r3,r3,-30076

The global entry point is:

<ns::foo1()>    lis     r2,4098
<ns::foo1()+4>  addi    r2,r2,32512

And the prologue is (note that the global entry point is included):

<ns::foo1()>    lis     r2,4098
<ns::foo1()+4>  addi    r2,r2,32512
<ns::foo1()+8>  mflr    r0
<ns::foo1()+12> std     r31,-8(r1)
<ns::foo1()+16> std     r0,16(r1)
<ns::foo1()+20> stdu    r1,-112(r1)
<ns::foo1()+24> mr      r31,r1

If the skip-prologue is turned off, the breakpoint will be placed in the first instruction:

<ns::foo1()>    lis     r2,4098

which is the global entry point that will not be executed when calling this function locally, see the call instruction:

<main(int, char const**)+128>        bl      0x100006f8 <ns::foo2()+8>

so the breakpoint is never reached.
Using the function pointer necessarily will execute the global entry point, so that is why I needed that.

[labath]

In D44101#1028435, @lbianc wrote:

About the environ symbol issue, I'm going to move to a separate test method in the same test file, is it ok?

Yes, that's fine.

The function pointer trick is necessary for power architecture, because it has a global entry point, which is not executed when calling the function locally (i. e. in the sabe context). There is a discussion about it here https://reviews.llvm.org/D43768?id=135917.
In this test case, the option skip-prologue is turned off before creating the breakpoint to that function, so consider the function:

Aha, I see what you mean now. However, I'm not convinced that working around the failure is the right thing to do here. For the lldb-server test that was fine because, all it cares about is setting a breakpoint somewhere in memory and making sure it gets hit -- it doesn't matter if that breakpoint is in a function with a global entry point, or even if it is in a function altogether. And the function pointer trick was just a way to steer the program execution to a well-defined address without resorting to assembly.

However, this looks like a different story. I don't think that whoever created the skip-prologue option even knew local entry points exist, but I think he would be surprised by the behavior you have here. And I am certain that I, as a user, would be very surprised (and upset) if setting skip-prologue=false would cause my breakpoints to not get hit in some (not so infrequent) conditions. So in light of the different entry points on ppc, I think we should read the "skip-prologue" option as "stop as early as possible" (while still making sure that you stop!), and treat this as a bug and not something that should be hacked around.

[clayborg]

packages/Python/lldbsuite/test/lldbtest.py

1251

s/is/if/

[lbianc]

However, this looks like a different story. I don't think that whoever created the skip-prologue option even knew local entry points exist, but I think he would be surprised by the behavior you have here. And I am certain that I, as a user, would be very surprised (and upset) if setting skip-prologue=false would cause my breakpoints to not get hit in some (not so infrequent) conditions. So in light of the different entry points on ppc, I think we should read the "skip-prologue" option as "stop as early as possible" (while still making sure that you stop!), and treat this as a bug and not something that should be hacked around.

Ok, that was one solution we have imagined. I'm going to revert the change of the function pointer for this patch, and create another one with the solution you asked, as it would be in a different context than testing.
Thanks!

[clayborg]

If you need to force something to use a global entry point you might be able to switch this test to use a shared library that contains that function. This would then require that the global entry point is used?

[lbianc]

If you need to force something to use a global entry point you might be able to switch this test to use a shared library that contains that function. This would then require that the global entry point is used?

Probably yes. We can think about a test case after the change to do not apply the breakpoint in the global entry point using shared library.

[lbianc]

Reverted changes of
packages/Python/lldbsuite/test/tools/lldb-mi/breakpoint/main.cpp.

Added a new test function for testing the value of environ symbol.

Other minor changes.

[lbianc]

@labath Could you please commit this change?

packages/Python/lldbsuite/test/expression_command/test/TestExprs2.py

def test_more_expr_commands(self):
         self.runCmd("run", RUN_SUCCEEDED)
 
         # Does static casting work?
         self.expect("expression (int*)argv",
                     startstr="(int *) $0 = 0x")
         # (int *) $0 = 0x00007fff5fbff258
 
         # Do anonymous symbols work?
-        self.expect("expression ((char**)environ)[0]",
+        self.expect("expression ((char**)__environ)[0]",
                     startstr="(char *) $1 = 0x")
         # (char *) $1 = 0x00007fff5fbff298 "Apple_PubSub_Socket_Render=/tmp/launch-7AEsUD/Render"
 
         # Do return values containing the contents of expression locals work?
         self.expect("expression int i = 5; i",
                     startstr="(int) $2 = 5")
         # (int) $2 = 5
         self.expect("expression $2 + 1",

packages/Python/lldbsuite/test/functionalities/thread/jump/TestThreadJump.py

def test(self):
                 'stop reason = breakpoint 1'])
 
         # Try the int path, force it to return 'a'
         self.do_min_test(self.mark3, self.mark1, "i", "4")
         # Try the int path, force it to return 'b'
         self.do_min_test(self.mark3, self.mark2, "i", "5")
         # Try the double path, force it to return 'a'
         self.do_min_test(self.mark4, self.mark1, "j", "7")
+        # Expected to fail on powerpc64le architecture
+        if not self.isPPC64le():
             # Try the double path, force it to return 'b'
             self.do_min_test(self.mark4, self.mark2, "j", "8")
 
         # Try jumping to another function in a different file.
         self.runCmd(
             "thread jump --file other.cpp --line %i --force" %
             self.mark5)
         self.expect("process status",
                     substrs=["at other.cpp:%i" % self.mark5])
 

packages/Python/lldbsuite/test/lldbtest.py

class Base(unittest2.TestCase):
 
     def isMIPS(self):
         """Returns true if the architecture is MIPS."""
         arch = self.getArchitecture()
         if re.match("mips", arch):
             return True
         return False
 
+    def isPPC64le(self):
+        """Returns true is the architecture is PPC64LE."""
+        arch = self.getArchitecture()
+        if re.match("powerpc64le", arch):
+            return True
+        return False
+
     def getArchitecture(self):
         """Returns the architecture in effect the test suite is running with."""
         module = builder_module()
         arch = module.getArchitecture()
         if arch == 'amd64':
             arch = 'x86_64'
         return arch
 

packages/Python/lldbsuite/test/tools/lldb-mi/breakpoint/main.cpp

 #include <cstdio>
 
 namespace ns
 {
     int foo1(void) { printf("In foo1\n"); return 1; }
     int foo2(void) { printf("In foo2\n"); return 2; }
 }
 
-int x;
+int x; int (*foo1_p)();
 int main(int argc, char const *argv[]) { // BP_main_decl
     printf("Print a formatted string so that GCC does not optimize this printf call: %s\n", argv[0]);
   // This is a long comment with no code inside
   // This is a long comment with no code inside
   // This is a long comment with no code inside
   // BP_in_main
   // This is a long comment with no code inside
   // This is a long comment with no code inside
   // This is a long comment with no code inside
-    x = ns::foo1() + ns::foo2();
+    foo1_p = &ns::foo1;
+    x = foo1_p() + ns::foo2();
     return 0; // BP_return
 }

packages/Python/lldbsuite/test/tools/lldb-mi/data/TestMiData.py

def test_lldbmi_data_disassemble(self):
             (addr, addr + 0x10))
 
         # This matches a line similar to:
         # Darwin: {address="0x0000000100000f18",func-name="hello_world()",offset="8",size="7",inst="leaq 0x65(%rip), %rdi; \"Hello, World!\\n\""},
         # Linux:  {address="0x0000000000400642",func-name="hello_world()",offset="18",size="5",inst="callq 0x4004d0; symbol stub for: printf"}
         # To match the escaped characters in the ouptut, we must use four backslashes per matches backslash
         # See https://docs.python.org/2/howto/regex.html#the-backslash-plague
 
         # The MIPS disassembler never prints stub name 
-        if self.isMIPS():
+        if self.isMIPS() or self.isPPC64le():
             self.expect(["{address=\"0x[0-9a-f]+\",func-name=\"hello_world\(\)\",offset=\"[0-9]+\",size=\"[0-9]+\",inst=\".+?; \\\\\"Hello, World!\\\\\\\\n\\\\\"\"}",
                      "{address=\"0x[0-9a-f]+\",func-name=\"hello_world\(\)\",offset=\"[0-9]+\",size=\"[0-9]+\",inst=\".+?\"}"])
         else:
             self.expect(["{address=\"0x[0-9a-f]+\",func-name=\"hello_world\(\)\",offset=\"[0-9]+\",size=\"[0-9]+\",inst=\".+?; \\\\\"Hello, World!\\\\\\\\n\\\\\"\"}",
                      "{address=\"0x[0-9a-f]+\",func-name=\"hello_world\(\)\",offset=\"[0-9]+\",size=\"[0-9]+\",inst=\".+?; symbol stub for: printf\"}"])
 
     @skipIfRemote   # We do not currently support remote debugging via the MI.
     @skipIfWindows  # llvm.org/pr24452: Get lldb-mi tests working on Windows