[PATCH] D149996: [test] [ExecutionEngine] Skip the ExecutionEngine tests on mingw targets

Mon May 8 21:35:51 PDT 2023

lhames added a comment.

In D149996#4326212 <https://reviews.llvm.org/D149996#4326212>, @mstorsjo wrote:

> MSVC built executables don't export any symbols at all (they don't have a symbol table; they could have DLL-style exported symbols though, but this one doesn't). The MinGW built `lli.exe` does contain `___chkstk_ms` in the symbol table.

I think that we should export the symbols from `lli`. When compiler-rt is linked into JIT'd code we'll pick the definition from there (this is the Right Thing to do if we're trying to model a real link). When it compiler-rt isn't linked into JIT'd code (which it won't be in check-llvm tests) we'll fall back to the version in `lli`, which should be fine in practice.

> Are there any options I could inject here, to make it more verbose about what it does, to inspect the code generation vs linking cases here?
>
> As the `-mtriple=` option didn't seem to make any difference, I also tried modifying `sys::getDefaultTargetTriple()` to return an MSVC style triple, but even then, the MinGW built `lli.exe` fails with references to the MinGW style named `___chckstk_ms` symbol. So there's something in the Orc jit linking step that always goes for the MinGW style name here. What do I do to gain insight into what's actually going on in the Orc jit linking step?

I don't think the link step is going to be relevant here: I'm pretty sure the difference is in `X86TargetLowering::getStackProbeSymbolName`:

  // We need a stack probe to conform to the Windows ABI. Choose the right                                                                                                                                                                                                                               
  // symbol.                                                                                                                                                                                                                                                                                             
  if (Subtarget.is64Bit())
    return Subtarget.isTargetCygMing() ? "___chkstk_ms" : "__chkstk";

You could break on this function and check the return value to verify this.

I think `lli` takes the triple from the first input file. Does any of your IR have triples in it?

> In D149996#4326193 <https://reviews.llvm.org/D149996#4326193>, @sgraenitz wrote:
>
>> One more guess: Could this function possibly reside in a runtime library for MinGW?
>
> The function normally does reside in a runtime library, yes, either libgcc or compiler-rt builtins. However in the MSVC case, the corresponding `__chkstk` function also is required, and is provided by a toolchain runtime library in the same way. How do I see if the linking step does resolve that symbol, and from where?

There's `-debug-only=orc`, but that's going to tell us (very verbosely) that it couldn't find the symbol in any of the places that It was told to look. In `lli` the places that it will look are (1) the set of input files, then (2) any extra archives, then (3) symbols exported by the process.

>> `lli` has `--orc-runtime` but it's not in use implicitly. As far as I know, we only support MSVC. Would MinGW support be interesting? Do we have anything in place? Maybe @sunho knows more about it. Thanks!
>
> I guess it might be interesting - but as you say, that's not happening implicitly for the MSVC case here either.
>
> Also just to set the scope here; I'm primarily working towards having `check-llvm` (and similar for other tools) run successfully in MinGW configurations - there are holes to fill in in various components, so I can't take on full the "let's implement everything" role right now; I just want to either flag known failing cases as such, and for trivial cases (like this seems like it would be), fix it by figuring out what is differing between the MSVC and MinGW cases.

Yeah -- Conceptually we want an ORC-runtime-lite embedded in LLVM to handle `check-llvm` cases (otherwise LLVM testing would depend on compiler-rt). In practice ORC-runtime-lite (especially when it comes to compiler-rt symbols) is usually going to involve either exporting the compile-rt symbol from the executable, pointing the symbol at abort (or something like it) if it's not actually intended to be used, or writing a simple implementation in LLVM's ORC library.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149996/new/

https://reviews.llvm.org/D149996