[LLVMdev] Re: LLVM to SUIF-MACH VM binary

[Reid Spencer]

A couple notes on this:

1. We also need to be able to *read* .o files for linking. Right now we
   just assume that any symbol not found in a bytcode file is
   implemented in some native library and will be resolved at runtime.
   This isn't the greatest assumption. To resolve native binary symbols
   we need to be able to read native .a, .so, and .o files to ensure 
   the symbols are resolvable at runtime (or to actually resolve them if
   we're building a native executable).

2. GNU has a library, BFD, part of binutils suitable for writing binary
   object files in the native format of a given host machine. It
   provides a common interface and abstraction (format neutral) for 
   reading and writing at least ELF and COFF files. The only thing it
   doesn't do well is translating between file types. There can be some
   loss of information between the various file formats. 

3. The linking side of this effort should end up in lib/Linker

Reid.

On Tue, 2005-01-18 at 08:12, Chris Lattner wrote:
> On Tue, 18 Jan 2005, John Cortes wrote:
> > Hi Chris,
> 
> Hi!  I'm CC'ing the llvmdev list for the benefit of others.
> 
> > Since I see you're very involved in LLVM, I need a little guidance on getting 
> > from C to MACH-SUIF.
> >
> > I've been given the task of using LLVM to translate C code to another VM 
> > architecture known as MACH-SUIF.  For this architecture, i don't think 
> > there's an assembler (but there is a disassembler), so I'm going to have to 
> > generate a binary file output.
> 
> Okay, that by itself shouldn't be a problem.  We do not currently support 
> emitting .o files directly, but it has been planned for quite some time.
> 
> > Could I edit and add to the .../lib/Target directory and add in a new target 
> > that outputs the binary that this new VM supports?  Do you think I would need 
> > to add to any other directories withing the LLVM directories?
> 
> The bulk of your work will certainly be in your lib/Target directory.  I 
> would start simple, and use the debugging output (enabled with 
> -print-machineinstrs) to see if you're generating correct code when you 
> start.  The code you have to add outside of lib/Target should be 
> restricted to the work needed to get .o files writing.
> 
> For your project, the tricky part will be that you have to start emitting 
> .o files before you can really test out the system.  This increases the 
> number of dependencies that need to implemented before you can get 
> "void main() {return;}" running, which is always the first milestone.
> 
> In order to get .o files writing, you'll want to implement the CodeEmitter 
> interfaces, which are used to write binary machine code to memory 
> (currently used by the JIT).  After that, you'll also want to add your new 
> support for writing .o files (which is basically just adding file headers 
> and packaging up relocations).  For this, you can choose to either add a 
> new virtual method to the TargetMachine class "addPassesToEmitObjectFile", 
> which will enable your functionality, or you can build it into the LLC 
> tool directly.  If you chose to build it into LLC, you can use the results 
> of the MachineCodeEmitter and addPassesToEmitMachineCode.  At this point, 
> I'm not sure which way will work best for you.
> 
> If possible, it would be nice if you could make your .o file writing code 
> as target-independent as possible (potentially defining a new 
> TargetObjectFile interface for any hooks you need).  In particular, if 
> MACH-SUIF is an ELF-based system, it would be nice to be able to use the 
> ELF-specific routines to write X86-ELF or PPC-ELF files as well (assuming 
> the hooks were implemented).  Clearly you can choose to worry about this 
> or not at your discretion.
> 
> Can you say a little bit about MACH-SUIF?  With a brief google search, I 
> didn't turn up anything that described the architecture.  Is it a 
> RISC-like machine with 32-bit instruction words?
> 
> -Chris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20050118/27461e27/attachment.sig>