✅ With the latest revision this PR passed the C/C++ code formatter.

(fixed formatting)

A related question to @lhames: do you see any way to work around this issue using the C-API and configure OrcV2 so that it correctly sets these flags when using a custom linking layer? Thank you 🙇

A related question to @lhames: do you see any way to work around this issue using the C-API and configure OrcV2 so that it correctly sets these flags when using a custom linking layer? Thank you 🙇

If your fix is sufficient for you for now i'd prefer not to expose these flags through the C API as they're workarounds for deficiencies in our current implementation. The eventual hope is to remove them, but I'm busy with other tasks at the moment and don't have time to do this work at the moment.

Great, thank you. Let's use this version then instead of adding bindings of those methods.

Regarding the workaround: this is making a number of LLVM versions unusable for my project on Windows, so I was just wondering if you see some other way to set those flags that doesn't need changes in LLVM itself. (Maybe by creating a default linking layer and then retroactively applying the customization from the custom link layer) But I'm assuming it's not possible with the C API.

Also: If/when RTDyldObjectLinkingLayer is deprecated, what will happen to C-API functions like LLVMOrcCreateRTDyldObjectLinkingLayerWithSectionMemoryManager or LLVMOrcCreateRTDyldObjectLinkingLayerWithMCJITMemoryManagerLikeCallbacks? Do you plan to adapt these bindings the RTDyldObjectLinkingLayer replacement, or will there be a new set of APIs?

I adapted the commit to address a merge conflict caused by conflicting changes on master.

Great, thank you. Let's use this version then instead of adding bindings of those methods.

Regarding the workaround: this is making a number of LLVM versions unusable for my project on Windows, so I was just wondering if you see some other way to set those flags that doesn't need changes in LLVM itself. (Maybe by creating a default linking layer and then retroactively applying the customization from the custom link layer) But I'm assuming it's not possible with the C API.

I think the LLVM change is the right way to go for now.

Also: If/when RTDyldObjectLinkingLayer is deprecated, what will happen to C-API functions like LLVMOrcCreateRTDyldObjectLinkingLayerWithSectionMemoryManager or LLVMOrcCreateRTDyldObjectLinkingLayerWithMCJITMemoryManagerLikeCallbacks? Do you plan to adapt these bindings the RTDyldObjectLinkingLayer replacement, or will there be a new set of APIs?

They will also be deprecated.

There is no C API replacement for these yet. We'll need to implement new APIs for this.

What customizations are you using? Do you need to control layout, or just find out where particular sections / symbols are?

What customizations are you using? Do you need to control layout, or just find out where particular sections / symbols are?

I need to control the layout. I am using LLVMOrcCreateRTDyldObjectLinkingLayerWithMCJITMemoryManagerLikeCallbacks to place generated code into a flat buffer that can contains everything (code, data). The program only uses %rip-relative accesses. An application can later map this data into memory and run it without using any of the LLVM infrastructure.

These are entirely self-contained computational kernels that don't use any external functionality (e.g. from libc).

@lhames: I incorporated the feedback but left in the COFF check, which was missing in your snippet (which I assume was unintentional).

What customizations are you using? Do you need to control layout, or just find out where particular sections / symbols are?

I need to control the layout. I am using LLVMOrcCreateRTDyldObjectLinkingLayerWithMCJITMemoryManagerLikeCallbacks to place generated code into a flat buffer that can contains everything (code, data). The program only uses %rip-relative accesses. An application can later map this data into memory and run it without using any of the LLVM infrastructure.

These are entirely self-contained computational kernels that don't use any external functionality (e.g. from libc).

This will be interesting. The JITLink and JITLinkMemoryManager APIs are much more complex than RuntimeDyld. I don't think we can expose the raw C API for this.

Do you actually need to control where the JIT'd memory lives, or just its layout? I'm wondering if we could get by with a "SectionMerger" plugin that merges all blocks into a single section with RWX permissions, plus maybe a custom section-based memory manager if you need to control where it goes?

Alternatively we could expose an API that allows you to merge simple LinkGraphs directly into a flat buffer, then we expose the existing SectCreate utility that allows you to add buffers directly to the JIT with a given set of permissions and associated symbols. (This wouldn't let you control its final load address though)

Do you actually need to control where the JIT'd memory lives, or just its layout? I'm wondering if we could get by with a "SectionMerger" plugin that merges all blocks into a single section with RWX permissions, plus maybe a custom section-based memory manager if you need to control where it goes?

I don't need control over the absolute address, just having a single section will be enough. A SectionMerger plugin, if accessible through the C API, would be perfect (and likely much simpler than the current workaround with the memory manager).

The other option honestly sounds fine as well :). The main requirement is that there is a way to pack code+data into a single section (no matter its absolute address), via the C API.

Looks like this is causing crashes in MLIR. Unfortunately I don't have access to a Windows machine to debug these.

I've asked the #mlir channel on Discord if they're able to reproduce. If you have a debug build handy you might be able to take a look too? The logs show an unhandled Expected value, so I suspect we have two problems: an error plumbing issue, and then whatever issue is raising the error.

@lhames Is it possible that removing the if statement from before was the cause of this regression? I reverted that last commit so that the MLIR team can check.

Dear @lhames,

I was wondering what I could do to get this unblocked. Current LLVM builds crash with my project when used on Windows because of this issue. Does this current commit still crash in the MLIR test suite after I reverted the latest change?

Hi Wenzel,

Sorry for the late reply — I’ve been out on vacation since early April. I’m back next Monday and should be able to look into this later in the week.

Thanks for your patience!

Thank you @lhames, please let me know if I can help with anything.

This specific fix aside, I am also wondering if we discuss (perhaps in a separate issue) a way to link into a flat buffer that has better long-term stability as the currently broken API is also on the way out. (You mentioned the following two potential paths that sound like they would work)

I'm wondering if we could get by with a "SectionMerger" plugin that merges all blocks into a single section with RWX permissions

Alternatively we could expose an API that allows you to merge simple LinkGraphs directly into a flat buffer, then we expose the existing SectCreate utility that allows you to add buffers directly to the JIT with a given set of permissions and associated symbols. (This wouldn't let you control its final load address though)