[LLVMdev] RFC: MCJIT enhancements

[Paweł Bylica]

On Wed, Jul 25, 2012 at 12:24 AM, Kaylor, Andrew <andrew.kaylor at intel.com>wrote:
>
>  -------------------------------****
>
> ELF Support on Windows****
>
> -------------------------------****
>
>  ****
>
> There are various reasons that it would be nice to be able to support
> generation of ELF objects on Windows through the MCJIT interface, one of
> which is that it would allow users to debug JITed code with GDB (i.e.
> MinGW).  There was a proposal by Eli Bendersky to enable ELF generation on
> Windows by extending the target triple handling.  We have been using that
> approach, and it works.  However, at the time it was proposed there seemed
> to be a general feeling that it would be preferable to have a general way
> to specify a non-default object format for any platform rather than a
> Windows/ELF-specific extension.****
>
>   ****
>
> The original discussion can be found here:****
>
>  ****
>
>
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120130/136053.html
> ****
>
>  ****
>
> Unfortunately, I don't believe a consensus was ever reached as to what the
> correct way to implement this would be.  I'd like to re-open that
> discussion now so that we can find a solution that would be generally
> accepted for inclusion in LLVM.
>

I'm using this patch mentioned and it works just fine.
However, I would like to see it implemented in more generic way:

1. When a container type is explicitly specified in triple it should be
used by MCJIT.
2. When a container type is not specified it is deduced from OS.
3. Use ELF by default.

"Environment" part of the triple may be used to specify the container. Some
options are already there (like MachO). But there may conflicts exist where
both environment and container must have been specified together (e.g.
"arm-apple-ios-eabi-macho").

- Paweł
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120816/90a05e3a/attachment.html>