[all-commits] [llvm/llvm-project] 6335de: [lldb/test] Use SBPlatform info for lldbplatformut...

[Pavel Labath via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 6335deb68b1dd417da4dff4f36fc344d8656e81a
      https://github.com/llvm/llvm-project/commit/6335deb68b1dd417da4dff4f36fc344d8656e81a
  Author: Pavel Labath <pavel at labath.sk>
  Date:   2022-11-29 (Tue, 29 Nov 2022)

  Changed paths:
    M lldb/packages/Python/lldbsuite/test/dotest.py
    M lldb/packages/Python/lldbsuite/test/lldbplatformutil.py

  Log Message:
  -----------
  [lldb/test] Use SBPlatform info for lldbplatformutil.getPlatform()

Previously, we just used the platform name. This worked mostly OK, but
it required adding special handling for any unusual (and potentially
downstream) platform plugins, as evidenced by the hardcoding of the
qemu-user platform.

The current implementation was added in
D121605/21c5bb0a636c23ec75b13681c0a6fdb03ecd9c0d, which this essentially
reverts and goes back to the previous method of retrieving the platform
name from the platform triple (the "OS" field).

The motivation for D121605 was the ability to retrieve the process
without constructing an SBDebugger object (which would be necessary in a
world where SBPlatforms are managed by SBDebuggers). However, this world
did not arrive (mainly due to other commitments on my part), and I now
think that if we do want to go in that direction, that we should just
create a dummy/empty SBDebugger object for holding the initial
SBPlatform.

One benefit of D121605 was the unification of getPlatform and
getHostPlatform code paths, and I preserve that benefit by unifying them
in the other direction -- using the host SBPlatform for getHostPlatform.

Differential Revision: https://reviews.llvm.org/D138430