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

Bendersky, Eli eli.bendersky at intel.com
Wed Feb 1 03:12:02 PST 2012


> Thanks for the patch. Couple questions/concerns:

Eric, thanks for the review. My answers below:

> 
> a) Have you seen the win32 in macho work? Thoughts on how that applies
> here?

As we discussed on IRC, I'm not really sure what this refers to. Conceptually, the new ELF environment type was added modeled on the existing MachO type. If you look around for "Triple.getEnvironment() == Triple::MachO" you'll actually see that a similar "container override" was already implemented for MachO (hmm, is this what you're referring to as the win32 macho work?)

> 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.
>

ExecutionEngine uses the triple defined in the module. This triple can be overridden, by setting the module triple. This is actually already done in lli.cpp - it accepts a "-mtriple" argument that can override the module's triple:

 	 // If we are supposed to override the target triple, do so now.
  	if (!TargetTriple.empty())
  	  Mod->setTargetTriple(Triple::normalize(TargetTriple));

The real problem is elsewhere. To put it simply, MCJIT uses LLVMTargetMachine::addPassesToEmitMC to eventually generate an object file from MC. When MC decides which object file to create, it's currently just looking at the OS component of the target triple, and decides COFF if it sees Windows, etc. (with the exception of checking for MachO, as mentioned above). Actually, the only way to currently affect the object file format is to set the triple. So to get an ELF object file on Windows we have to change some things.

As I previously mentioned, 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 patch takes approach (3). Approach (2) would also be relatively simple (and perhaps cleaner, except making Triple a 5-tuple instead of 4-tuple). Approach (3) seems (to my neophyte self) much more complex, as MC's and Target's reliance on the triple to decide on the object file format goes deep. A look at the code of the patch shows which parts of the code have to be touched to make the container override work.

While we would be happy to have this patch in, we fully understand the need to come up with a solution people feel comfortable with. Discussion on this topic would be very welcome.

Eli


















> 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

---------------------------------------------------------------------
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.





More information about the llvm-commits mailing list