[JITLink] [test] Extend preexisting MinGW XFAILs to new tests

[mstorsjo]

This extends the preexisting XFAILs from
4c642b6 to these new tests from 6fa8657.

[lhames]

@mstorsjo Do any of the JIT test cases work on MinGW?

If the JIT is close to working there then we could fix this by adding a definition of __main to be loaded by default for MinGW triples.

If the JIT isn't close to working then we could probably just disable the JITLink tests completely on MinGW.

[mstorsjo]

@mstorsjo Do any of the JIT test cases work on MinGW?

If the JIT is close to working there then we could fix this by adding a definition of __main to be loaded by default for MinGW triples.

If the JIT isn't close to working then we could probably just disable the JITLink tests completely on MinGW.

I think the JIT is generally working (sorry I don't really know the nuance differences between the various JIT implementations); we tweaked things in the lli executable a couple years ago in cbc2a06 in order to make tests pass. I think the ORC runtime isn't set up to work in mingw mode though. But overall, up until last week all tests passed with ninja check (although some of them are marked as unsupported or XFAIL).

[mstorsjo]

If the JIT is close to working there then we could fix this by adding a definition of __main to be loaded by default for MinGW triples.

Do you have any suggestion on where/how to do this?

Could we merge this first, to get the tests back to green first, and then look into providing __main and getting rid of these XFAILs?

[lhames]

I think it's fine to land these, but it'd be good to add a FIXME to reenable them once we add __main emulation to ORC?

The ORC runtime isn't relevant here, but the RuntimeDyld / JITLink distinction is: These are llvm-jitlink tests for the new JIT linker. The pure assembly cases are hand written, so have no reference to __main, but the new .ll ones are compiled by llc which will add a reference -- that's probably what's caused the difference.

[mstorsjo]

I think it's fine to land these, but it'd be good to add a FIXME to reenable them once we add __main emulation to ORC?

Luckily, as they're XFAIL, it'll be a red failure again if it does start passing without updating the tests. :-) But if you prefer I can add a FIXME comment about it there as well - would you prefer that next to the XFAIL in the tests, or elsewhere?

The ORC runtime isn't relevant here, but the RuntimeDyld / JITLink distinction is: These are llvm-jitlink tests for the new JIT linker. The pure assembly cases are hand written, so have no reference to __main, but the new .ll ones are compiled by llc which will add a reference -- that's probably what's caused the difference.

Yep; fwiw I noted that lli does hook up a dummy __main similarly already:

llvm-project/llvm/tools/lli/lli.cpp

Lines 1083 to 1089 in eb71fdd

	// If this is a Mingw or Cygwin executor then we need to alias __main to
	// orc_rt_int_void_return_0.
	if (J->getTargetTriple().isOSCygMing())
	ExitOnErr(J->getProcessSymbolsJITDylib()->define(
	orc::absoluteSymbols({{J->mangleAndIntern("__main"),
	{orc::ExecutorAddr::fromPtr(mingw_noop_main),
	JITSymbolFlags::Exported}}})));

[lhames]

Luckily, as they're XFAIL, it'll be a red failure again if it does start passing without updating the tests. :-)
Good point. That will do. ;)

[lhames]

Yep; fwiw I noted that lli does hook up a dummy __main similarly already:

Yep. Having a no-op __main will probably be sufficient to get the tests passing (certainly it'll address the missing symbol error).

Ideally we'd figure out what __main's role in a regular program is and emulate it (a no-op might even be the right operation in a JIT context, but if so we should verify and document that).