[LLVMdev] LLVM "Native" Backend
Christopher Lamb
christopher.lamb at gmail.com
Sun Mar 18 09:56:40 PDT 2007
On Mar 17, 2007, at 4:09 PM, Chris Lattner wrote:
> On Fri, 16 Mar 2007, Christopher Lamb wrote:
>> Having read through the documentation and browsed the code what
>> are the
>> missing pieces, if any, required to implement a "native" LLVM
>> backend that:
>> * is able to produce loadable (ELF) object files with DWARF debugging
>> information
>> * handle inline assembly
>> * perform linker all necessary linking fixups
>
> Sure, this should be no problem. I'd start with the sparc backend,
> it's
> very simple and straight-forward place to start.
>
> LLVM can currently produce .o files directly in some limited cases,
> or you
> can go through an assembler, which is much more robust. Any help
> improving the direct ELF writer would be appreciated.
Which of the LLVM tools can currently produce .o files directly
without going through the platform's as/ld? How do I specify this on
the command line to any of the tools?
>
>> This assumes that there will be no native object file linking
>> stage in the
>> tool chain.
>
> LLVM works will your standard tool components, like the gnu linker,
> assembler, etc.
I'm primarily considering this as an option for a custom target. My
interest is in not having to do a binutils port, so currently I have
no "real" assembler and linker.
>
>> From what I can tell the ELF writer should be able to produce the
>> object
>> files, but a DWARF-in-ELF writer would have to be created to
>> insert the
>> debugging information into the ELF file.
>
> Yep
>
>> Either the inline assembly would be reverse compiled or handled by
>> custom
>> pass. I'm not sure what the options are here...
>
> Inline asm is very tricky, it basically amounts to LLVM having an
> assembler for each target. We're not oppposed to this, but it is a
> significant amount of work.
Is there an infrastructure in place (or a design) to work on such an
inline assembler? I'd think that a lot of the tblgen information used
for the Code/Asm emitters could be reused for this.
--
Christopher Lamb
More information about the llvm-dev
mailing list