similar to: [LLVMdev] LLVM "Native" Backend

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

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

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

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

On Oct 30, 2012, at 11:10 AM, Shankar Easwaran wrote: >>> >>> 3) How are you planning to support Atom specific flags ? Is there a way already ? >>> (This would be needed to group similiar atoms together) >> It is still an open question how to support platform specific Atom attributes. As much as possible we'd like to expand the Atom model to be a superset

On Mar 30, 2007, at 12:35 PM, Christopher Lamb wrote: > > 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

Thanks for the reply Nick. 1) Is there a way to validate that the input file is of a valid format, thats defined by the YAML Reader ? > Do you mean different than if the yaml reader accepts it? Tons of > files will be valid yaml syntactically. It is the semantic level > checking that is hard, and that is what YAML I/O does. > Yes, if the YAML reader accepts it and figures out that

Hi Nick, Thanks for your reply. How about if the atom flags could be overridden ? The Atom flag could have a MIN/MAX and anything above the MAX or lower than the MIN are platform specific, like how its dealt with section indexes ? > I know ELF file format has some ranges for various values that are specifically reserved for processors or "user" defined functionality. It serves the

On Oct 30, 2012, at 7:12 AM, Shankar Easwaran wrote: > Hi Nick, > > I had a few questions :- > > 1) Is there a way to validate that the input file is of a valid format, thats defined by the YAML Reader ? Do you mean different than if the yaml reader accepts it? Tons of files will be valid yaml syntactically. It is the semantic level checking that is hard, and that is what

Hello! I am working with LLVM project to compile for specific processor (xPEC-processor from NetX chip, http://hilscher.com/ ). I have done support of this target successfully! Assembler code can be emitted with debug information. LLVM - great!) But now I am looking for generation of machine code for my target. I have seen, that "llc" has option "-filetype". It has

Debug info linking is currently broken due to how we handle reading and laying out non SHF_ALLOC sections. I posted a patch that partially fixes this, but it's both the wrong approach and doesn't handle multiple input files with debug info (wrong relocation values). The first issue is representing non SHF_ALLOC atoms in the Atom model. We currently don't have a type for this, and

On Mon, Jul 27, 2009 at 8:25 AM, Rudskyy<tema13tema at yahoo.de> wrote: > But now I am looking for generation of machine code for my target. I have > seen, that “llc” has option "-filetype". > > It has default value "-filetype=asm", but has more values, as > "-filetype=obj" and "-filetype=dynlib". > > “obj” is very interesting, but

----- Original Message ---- > From aaronngray.lists at googlemail.com Mon Jul 27 15:14:40 2009 > From: aaronngray.lists at googlemail.com (Aaron Gray) > Date: Mon, 27 Jul 2009 21:14:40 +0100 > Subject: [LLVMdev] llc - generation of native machine code > > > On Mon, Jul 27, 2009 at 8:25 AM, Rudskyy<tema13tema at yahoo.de> wrote: > > > But now I am looking for

On Fri, 30 Mar 2007, Christopher Lamb wrote: >> Should I try to submit a patch for the partial work that I've done? > > Should a PR be opened for ELF output? Sure, that would be a good way to track the feature. Patches should be sent to llvm-commits. -Chris -- http://nondot.org/sabre/ http://llvm.org/

On Nov 21, 2007, at 6:22 PM, Chris Lattner wrote: > On Wed, 21 Nov 2007, Christopher Lamb wrote: >>> Unlike alignment and volatility, I think that the address space >>> qualifier >>> should be represented explicitly in the type system. The reason >>> for this > >> I've come across a hitch. Store instructions do not reference the

On Nov 11, 2007, at 9:52 AM, Chris Lattner wrote: > > On Nov 10, 2007, at 11:07 PM, Christopher Lamb wrote: > >> I've been playing around with clang/LLVM looking at adding partial >> support for the draft technical report for embedded C extensions >> (TR18037, http://www.open-std.org/jtc1/sc22/wg14/www/docs/ >> n1169.pdf), specifically named address

I've been playing around with clang/LLVM looking at adding partial support for the draft technical report for embedded C extensions (TR18037, http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf), specifically named address spaces. Named address spaces need to be tracked in LLVM in essentially all the same places that alignment is tracked, which necessitates adding the

Hi Jason, Jim, Rafael, We had plans to work on ARM MC (asm and elf), good to see there is an interest, and we'd be glad to help. The ARM part of MC is almost empty, so there's a lot of work in there, probably even before writing the assembly/ELF writers. Also, AFAIK, there is no ELF writer for MC, so wouldn't be good to write one specific for the ARM platform, but keep things generic

Michael, To validate the refactor of YAML Reader/Writer using YAML I/O. I updated all the test cases to be compatible with YAML I/O. One issue that was a gnarly was how to handle the test cases with archives. Currently, we have test cases like: --- atoms: - name: foo # more stuff --- archive: - name bar.o atoms: - name: bar # more stuff This sort of

On Wed, 21 Nov 2007, Christopher Lamb wrote: >> Unlike alignment and volatility, I think that the address space qualifier >> should be represented explicitly in the type system. The reason for this > I've come across a hitch. Store instructions do not reference the pointer > type in the .bc format, only the stored type. The .bc reader constructs the > pointer type