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 This assumes that there will be no native object file linking stage in the tool chain. 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. Either the inline assembly would be reverse compiled or handled by custom pass. I'm not sure what the options are here... Am I on the right track? -- Christopher Lamb christopher.lamb at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070316/ef9bbe15/attachment.html>
Hi Christopher, On Fri, 2007-03-16 at 16:57 -0500, 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 > > > This assumes that there will be no native object file linking stage in > the tool chain.Which assumes that there's only one translation unit. Given that scenario, its doable, currently.> > > 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.We currently support DWARF/ELF on x86 and PPC. Not sure about other back ends.> > > Either the inline assembly would be reverse compiled or handled by > custom pass. I'm not sure what the options are here...Inline assembly is well supported although not as completely as gcc. For example, it provides enough to compile the Linux kernel.> > > Am I on the right track? > -- > Christopher Lamb > christopher.lamb at gmail.com > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
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 fixupsSure, 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.> 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.> 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. -Chris -- http://nondot.org/sabre/ http://llvm.org/
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