[PATCH] D22370: Respect LLVM_HOST_TRIPLE when manually specified

[Luke Drummond via llvm-commits]

ldrumm added a comment.

In https://reviews.llvm.org/D22370#486859, @beanz wrote:

> `LLVM_HOST_TRIPLE` is not intended to match the target, and it shouldn't be used in situations where it must match the target. I'm not familiar with how lldb builds the remote server in CMake, but using `LLVM_HOST_TRIPLE` is not the right answer.


>From the documentation I can see, that's not the case. Indeed `sys::getProcessTriple` is documented here <http://llvm.org/docs/doxygen/html/namespacellvm_1_1sys.html#aab375071f641a086c0d7067635ccd3dc> as follows:

> Return an appropriate target triple for generating code to be loaded into the current process, e.g.

> when using the JIT.


Its implementation <https://github.com/llvm-mirror/llvm/blob/master/lib/Support/Host.cpp#L1333> is a simple wrapper around the  `LLVM_HOST_TRIPLE` macro

  std::string sys::getProcessTriple() {
    Triple PT(Triple::normalize(LLVM_HOST_TRIPLE));
  
    if (sizeof(void *) == 8 && PT.isArch32Bit())
      PT = PT.get64BitArchVariant();
    if (sizeof(void *) == 4 && PT.isArch64Bit())
      PT = PT.get32BitArchVariant();
  
    return PT.str();
  }

`getProcessTriple` is then used in lldb and lldb-server to compute options at startup <https://github.com/llvm-mirror/lldb/blob/master/source/Host/common/HostInfoBase.cpp#L400>

Whether this meets the /intended/ use here is a philosophical question (albeit one that's answered here <https://github.com/llvm-mirror/llvm/commit/fbb662f840c2f76988ff9f3f152695632cfc71be>). Right now, we need this to match the triple to the cross-compiled binary, and forcing this to be win32 is incorrect in a cross-compilation situation. If this is a bug in the documentation for `getProcessTriple`, I'm happy to fix it, but this looks like lldb-server *is* using getProcessTriple in the intended way according to the commit message for it's initial implementation, as well as the Doxygen docs, so there shouldn't anything wrong with setting this.


Repository:
  rL LLVM

https://reviews.llvm.org/D22370