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

[John Cortes]

Reid Spencer wrote:
> 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.
> 

Thanks for the heads up.  Once I get further along on my project, I'll have to 
look into this.  For right now we're going from one VM IR to another VM IR, so I 
guess it's generating bytecode instead of object code for now.

John


> 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