[llvm] [MCJIT] Fix frem.ll test failure with LLVM_ENABLE_RPMALLOC on Windows (PR #200319)

[Igor Kudrin via llvm-commits]

igorkudrin wrote:

> > BTW, maybe we can simply disable exporting symbols for lli.exe, for static-CRT configuration, or even completely? This would also resolve the initial issue, as modules would be forced to import symbols only from the dynamic CRT.
> 
> Yep -- that's worth trying. I'm not certain whether it will work though: some tests may rely on calling into LLVM code (unfortunately I don't recall whether we've eliminated this).

As far as I can tell, all tests pass when exporting symbols is disabled. What do you think about the updated patch?

> As a side note: We're trying to take an expansive position on what we support in the ORC JIT. The best way to think of ORC is as a weird static-linker + dynamic-loader. Seen this way, the cases you describe above aren't actually too hard to handle in general: JIT'd objects that should link against a dynamic CRT (even if there are multiple ones in process) needs a `DynamicLibrarySearchGenerator` constructed from the corresponding dynamic CRT's handle. JIT'd objects linking against a static CRT need a `StaticLibrarySearchGenerator` constructed from the given static CRT's path / file handle.
> 
> `lli`'s an odd case because we've never really specified how the JIT'd code that it runs should be treated. It was always just "try to resolve symbols in the process and assume that if they resolve everything will work". We're hitting the limits of that approach in this testcase. Formalising things to "always look in the dynamic CRT where present" is probably a step in the right direction.

Thanks for the explanation, but we are not going to implement this now, right?

https://github.com/llvm/llvm-project/pull/200319