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
On Sun, 18 Mar 2007, Christopher Lamb wrote:>> 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?llc -filetype=obj I think that this is disabled for ELF, but you can easily enable it. Macho works pretty well, but ELF is not entirely finished. Any help would be appreciated: basing the work on the macho writer would be appropriate.>>> 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.LLVM doesn't have any support for linking native objects, you will need to get this somewhere.>> 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.I agree with you, it should be a good starting place. However, we don't have the infrastructure for this yet. -Chris -- http://nondot.org/sabre/ http://llvm.org/
On Mar 18, 2007, at 7:05 PM, Chris Lattner wrote:> On Sun, 18 Mar 2007, Christopher Lamb wrote: >>> 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? > > llc -filetype=obj > > I think that this is disabled for ELF, but you can easily enable it. > Macho works pretty well, but ELF is not entirely finished. Any > help would > be appreciated: basing the work on the macho writer would be > appropriate.So I've increased the support for ELF writing, but it's certainly not done yet. I fixed a few bugs that were preventing it from emitting correct elf headers, so if there are no ELF relocations emitted (i.e. the target can handle all of the relocations at code emission) then this change set should allow one to write a perfectly valid ELF REL file. I've got preliminary support for relocations, the data structures to be precise, and refactored some of the ELF writer to be more like the MachO writer. Should I try to submit a patch for the partial work that I've done? -- Christopher Lamb christopher.lamb at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070330/9df41e62/attachment.html>