We’re currently working on MC-JIT, focusing on runtime generation and loading of ELF object files, even on non-ELF platforms (i.e. Windows). However, we run into a problem with MC insisting to generate COFF objects on Windows, MachO on Macs and ELF only otherwise, based on the triple.
Is there an existing method to generate ELF objects with MC on Windows, without modifying MC?
Thanks in advance,
Is there an existing method to generate ELF objects with MC on Windows,
without modifying MC?
Here "on windows" you mean you want to generate the ELF file with
windows-specific code inside?
Is there an existing method to generate ELF objects with MC on
Windows, without modifying MC?
Here "on windows" you mean you want to generate the ELF file with windows-specific code inside?
Yes, what I mean is that I want to generate runnable Windows code, on Windows, but package in ELF as the object file. Note that there's absolutely no problem with this approach - in fact we have a functional prototype already.
The reason for this is that I currently want to employ MC-JIT on both Linux and Windows, without implementing two separate runtime dynamic loaders. I want to implement just RuntimeDyldELF, and use it on both Windows and Linux.
Well... What will you do if you will need to support some
windows-specific binary stuff which does not exist in ELF world? I
cannot think about something in this area off-hand, but there might be
And surely there are MachO features which do not exist in ELF world.
The existence of tools like Wine, LBW and several MachO loaders on Linux is a good indication that at least in most cases, it's possible to run code packaged in some container format on a system favoring another container. In the worst case, the dynamic loader may explicitly choke on some special features, but empirically it seems that most code can run without problems (we successfully executed many non-trivial workloads packaged inside ELF on Windows).
I would have to back up Eli on this point. AMD uses an ELF on both Linux and windows for OpenCL and would like to have the ability to use the MC system to generate it instead of COFF.
Apart from Anton's concerns (which I think are manageable) and Micah's support, I received no reply on this.
Does there exist a way to tell MC to generate and ELF container for code on Windows? If not, I'm willing to submit a patch to fix this, but would like some opinions on the best direction to take here.
The proposed "llvm::TargetSpec class" (http://nondot.org/sabre/LLVMNotes/TargetSpec.txt) seems to address this, although AFAICS the current llvm::Triple does not explicitly specify the object/container type. ELF is usually taken as "default" when no other option is chosen. A representative example from X86MCTargetDesc.cpp:
Would it be OK to add "ELF" to Triple::EnvironmentType? It seems like a
plausible choice since MachO is there. On the other hand, I'm not sure
whether it makes sense to make it mutually exclusive with the other members
of EnvironmentType (GNU, GNUEABI, EABI).
EABI and GNUEABI imply ELF. GNU in practice does not need to imply ELF, but
is used in the ARM world as "the pre AAPCS ABI". I'm not certain, but I
don't think EnvironmentType is even used on non-ARM platforms, so you could
add an extra enumerator without affecting anything.
That said, I don't think the container is a property of the triple or even
the target selection. For example, we could generate flat-binary or ELF
output on ELF systems.
Some solution that doesn't tie the output format to the target would be
Thanks for the input. As the code sample I pasted shows, currently the container is directly inferred from the triple, looking at its "OSType" enum, with the exception of MachO also being selected based on getEnvironment() == Triple::MachO. The Triple seems to be the ubiquitous "configuration" object being passed around, according to which the container is eventually chosen.
The new llvm::TargetSpec class proposed in http://nondot.org/sabre/LLVMNotes/TargetSpec.txt also (explicitly) carries the container around.
Unfortunately I'm not familiar enough with these areas of the code to have a good idea of what alternatives there are to specify the container for MC. I'll be happy to hear any suggestions.
It could be we just need a temporary solution until llvm::TargetSpec is implemented.