[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