[LLDB] Fix TestTargetXMLArch's expected arch

[luporl]

Summary

When running on an architecture other than x86_64, the
target.ConnectRemote() part of the test may add platform information to
the target triple.

It was observed that this happens at Process::CompleteAttach() method,
after the platform_sp->IsCompatibleArchitecture() check fails.
This method then calls platform_sp->GetPlatformForArchitecture(), that
on a Linux machine ends up returning a generic Linux platform, that then
ends up getting added to the original target architecture.

[labath]

+jason, as he's the one who wrote this test.

I think that for these kind of tests, we should find a way to isolate them from the host differences and make sure they run the same way everywhere.

[jasonmolenda]

Pavel raises a good point, but I don't know if the onerous should be on this patch author to work out a better way to test this.

The question I have is -- what is the target triple on your linux system? Is the vendor field of the triple empty? To be honest, we could test for .startswith('x86_64-') here and that's all we really need to be doing. If the host platform is "infecting" the triple with a vendor or OS, that's not what the test is intended to check.

[labath]

Yeah, I didn't mean to suggest Leandro should be the one testing this. I meant "we" as a community.

If you say that checking for x86_64 is enough for this test, then maybe we can postpone that and just change the assertion, but I would like to get there eventually, as this can of a test has potential to be completely reproducible on all platforms, and it probably doesn't even take much to get there (maybe explicitly selecting a platform before creating a target, or finding a way to disable host-target fallbacks).

[luporl]

In D44022#1026098, @jasonmolenda wrote:

Pavel raises a good point, but I don't know if the onerous should be on this patch author to work out a better way to test this.

The question I have is -- what is the target triple on your linux system? Is the vendor field of the triple empty? To be honest, we could test for .startswith('x86_64-') here and that's all we really need to be doing. If the host platform is "infecting" the triple with a vendor or OS, that's not what the test is intended to check.

The native triple on my system is powerpc64le-unknown-linux-gnu. In the test, target.GetTriple() was returning x86_64--linux.

[luporl]

BTW, why is failure expected in i386?

@expectedFailureAll(archs=["i386"])

[luporl]

@labath, @jasonmolenda, any updates on this? Can we just change the assert for now?

[labath]

Based on Jason's comment above, it sounds like changing the assertion is good enough.

[luporl]

Thanks @labath. Can you check this in for me?

lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestTargetXMLArch.py

def test(self):
         if self.TraceOn():
             interp.HandleCommand("log enable gdb-remote packets", result)
         target = self.dbg.CreateTarget('')
         self.assertEqual('', target.GetTriple())
         process = self.connect(target)
         if self.TraceOn():
             interp.HandleCommand("target list", result)
             print(result.GetOutput())
-        self.assertEqual('x86_64--', target.GetTriple())
+        self.assertTrue(target.GetTriple().startswith('x86_64--'))