LLVM "Native" Backend

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

LLVM "Native" Backend

Christopher Lamb
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



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM "Native" Backend

Reid Spencer-2
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
> [hidden email]
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM "Native" Backend

Chris Lattner
In reply to this post by Christopher Lamb
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.

> 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/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM "Native" Backend

Christopher Lamb

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

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM "Native" Backend

Chris Lattner
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/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM "Native" Backend

Christopher Lamb

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



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM "Native" Backend

Christopher Lamb

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 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? 

Should a PR be opened for ELF output?

--
Christopher Lamb




_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM "Native" Backend

Chris Lattner
In reply to this post by Christopher Lamb
On Fri, 30 Mar 2007, Christopher Lamb wrote:
> 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.

Nice!

> Should I try to submit a patch for the partial work that I've done?

Absolutely.

-Chris

--
http://nondot.org/sabre/
http://llvm.org/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM "Native" Backend

Chris Lattner
In reply to this post by Christopher Lamb
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/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM "Native" Backend

Christopher Lamb

On Mar 30, 2007, at 2:40 PM, Chris Lattner wrote:

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

This is now PR1294. I'll work up a patch next week.

--
Christopher Lamb




_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev