[LLVMdev] MachO and ELF Writers/MachineCodeEmitters are hard-codedinto LLVMTargetMachine

[Aaron Gray]

> Currently, the MachO and ELF Writers and MachineCodeEmitters are
> hard-coded into LLVMTargetMachine and llc.

I am also interested in working on this area and interested in writting a 
COFF file backend.

> In other words, the 'object file generation' capabilities of the
> Common Code Generator are not generic.

I was looking at making a parallel class to MachineCodeEmitter, 
'MachineCodeWriter' that can be used generically instead of 
MachineCodeEmitter to write to a supplied 'vector<byte>'. This would not 
introduce any overhead to the existing runtime code and would allow inlining 
of writting functions in X86CodeEmitter and other emitters. They would have 
to be templated and the MCE member parameterized.

> LLVMTargetMachine::addPassesToEmitFile explicitly checks whether the
> derived backend TargetMachine implements one of getMachOWriterInfo or
> getELFWriterInfo, and returns a corresponding FileModel enum value.
>
> llc's main function uses the resulting FileModel value to determine
> which of the {AddMachOWriter,AddELFWriter} functions to call.
>
> This is limiting for a number of reasons:
> 1. If a given platform (e.g. x86) may support both MachO and ELF,
> MachO will be selected, as it is checked first. This is bad behaviour,
> it should be up to the user to decide which object format he wants.
> 2. Extension of the object file generation capabilities to include new
> object file formats is difficult, and requires modifications to LLVM
> code (not just a plugin).
>
> I suggest transforming the {getMachOWriterInfo, getELFWriterInfo}
> functions (on TargetMachine) into a single (templated?)
> getObjectFileWriterInfo function. Additionally a addObjectFileWriter
> member should be added  to TargetMachine, taking the place of the
> static {AddMachOWriter, AddELFWriter} functions.
>
> As I need this functionality (custom object file generation) for my
> current target, I'd be happy to make the modifications to the LLVM
> core. Before I do so, I'd like to get feedback on my proposed
> solution.
>
> I've added a bug for this issue: http://llvm.org/bugs/show_bug.cgi?id=3813

Aaron