[LLVMdev] MC-JIT Design

[Reid Kleckner]

On Mon, Nov 15, 2010 at 1:15 PM, Daniel Dunbar <daniel at zuster.org> wrote:
> #2 (aka FOOJIT) - MC grows a new "pure" backend, which is designed
> around representing everything that "can be run" on a target platform.
> This is very connected to the inherent capabilities of the hardware /
> OS, and is usually a superset** of what the native object format
> (Mach-O, ELF, COFF) can represent.
>
> The "pure" backend defines a hard (but non-stable) object file format
> which is more or less a direct encoding of the native MC APIs (it is
> not stable, so it can directly encode things like FixupKind enum
> values).
>
> I don't have a name for this format, so for now I will call it FOO.
>
> ...
>
> Thoughts?

One thing that's annoying about the current JIT is that it doesn't
integrate well into debugging, profiling, and instrumentation tools.
By changing the compilation model so that you emit discrete object
files in memory, it seems like you have the opportunity to integrate
with those kinds of tools more easily.  I'm wondering what the
tradeoffs are between just emitting a native object file into memory
are.

Alternatively, do you think the FOO object file format would be stable
enough to add to things like libbfd so tools can easily learn about
JITed code?  I'd imagine if you did this, you could just keep bumping
a version number if the format changes, and require people who want to
use tools on the JIT to use a current version of their tool.

Reid