[llvm-commits] FW: [PATCH] enabling generation of ELF objects on Windows with the help of the triple

[Eric Christopher]

Thanks for the patch. Couple questions/concerns:

a) Have you seen the win32 in macho work? Thoughts on how that applies here?
b) How about a way of initializing the JIT that takes the triple of the target you wish to generate code/information for rather than adding to the triple?

I think for the JIT it makes more sense for the interface to require a "container triple" which defaults to the current host.

Jim: Objections?
Eli: Thoughts? :)

-eric 

On Feb 1, 2012, at 12:57 AM, Bendersky, Eli wrote:

> Re-sending the patch itself (by request on IRC)
> 
> -----Original Message-----
> From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Bendersky, Eli
> Sent: Tuesday, January 24, 2012 15:03
> To: llvm-commits at cs.uiuc.edu
> Subject: [llvm-commits] [PATCH] enabling generation of ELF objects on Windows with the help of the triple
> 
> Hello,
> 
> Earlier this month I initiated a llvmdev discussion on the possibility to make MC generate code into an ELF container on Windows (http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-January/046583.html). Currently in several places in the code the decision is made based on the Triple's OS component. When it's Windows, a decision is made automatically to generate COFF, so a way is needed to let MC know that we still want ELF, even if we're on Windows.
> 
> There are several approaches to this:
> 
> 1. Add this information somewhere which isn't the Triple 2. Add this information into the Triple, making it a 5-tuple instead of 4-tuple - the 5th component being "container" or something like that 3. Add this information into the Triple, overlaying the "environment" component
> 
> The attached patch takes approach (3) since this appears to make the minimal overall impact on the code. It adds an "ELF" option to the EnvironmentType enum. Since we're interested in ELF on Windows on x86, this environment option doesn't conflict with the others. In other words, it enables us to generate and run MCJIT-ted code on Windows, without interfering with other code in LLVM.
> 
> Although approach (1) would perhaps be cleaner, it is not easy to see how to go about it, since in many places where the modification is required the triple is the only accessible piece of information about the compiler target. The decision to generate COFF on Windows is based on the Triple, not on something else.
> 
> I'll be happy to hear about other options, or to get this patch reviewed so I can commit it.
> 
> Thanks in advance,
> Eli
> 
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
> 
> This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> <windows_elf_triple.2.patch>_______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits