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

[Martin Storsjö via Phabricator via llvm-commits]

mstorsjo added a comment.

In D149996#4328634 <https://reviews.llvm.org/D149996#4328634>, @lhames wrote:

> 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.

I see here that this succeeds since it finds an exported `__chkstk` symbol in `kernelbase.dll` that happens to be loaded. (Normally, nothing ever imports the `__chkstk` symbol from another DLL, it's always a statically linked minimal helper function.) So that explains why it works with the `__chkstk` name but not for `__chkstk_ms`.

I guess making `lli` export symbols for them to be found at runtime, might be one solution, let me think about that a bit...

>> 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?

Yes, that code obviously is what picks the name. The IR doesn't have any triples in it - I'm running into this with e.g. https://github.com/llvm/llvm-project/blob/main/llvm/test/ExecutionEngine/MCJIT/test-loadstore.ll. When running without `-jit-kind=mcjit`, `lli` seems to ignore the triple specified with the `-mtriple` option, and it also doesn't react to changes to `sys::getDefaultTargetTriple()`. So where is the triple set that is used for code generation, when running that testcase with Orc? (I'm curious about where it picks up the msvc vs mingw difference,  if it's not from either of the `-mtriple` option or `sys:: getDefaultTargetTriple()`.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D149996