llvm dev - Apr 2005 - [LLVMdev] can bc/asm carry enough type info for C/C++ compiler/interpreter?

I am asking this question to see if it is possible or desirable to build a
compilation/runtime system for C/C++ that can support the following:

1. allow bc to call native (in dynamically loaded *.so)
2. allow native to call bc (through JIT or interpreter)
3. can compile/interpret C/C++ sources _BASED_ on type info in precompiled bc


Motivation:
The class files produced by the java compiler carries sufficient information
that another pass of compilation of java source can be done by including
clas/jar files only:

A.java => A.class
B.java => B.class
C.java => C.class
[ABC].class => ABC.jar
Now compilation of any java class (X) that refs A/B/C can be done with:
javac -cp ABC.jar X.java

This makes it easy to build java scripting engines (beanshell, jython, groovy)
that need to be able to compile java classes that refs existing compiled
classes.

For C/C++ there are 2 tools that are close to fullfilling a similar goal:
gcc+gdb and cint.

gdb: If an .so/.exe is compiled with gcc -g there is enough type info in the
debugging symbols that gdb can later print fields of structs. Theoretically you
can use gdb to ptype all the relevant types and reproduce all the headers for
another pass of compilation.
cint: a C/C++ interpreter that interpret the .h.cxx files directly but also able
to call funcs in native solibs. HOWEVER, to interpret code that refs funcs in
the precompiled solibs, cint has to parse the relevant headers used by the
precompiled solibs and cint has many limitations compared to gcc/g++ parser.

Given that llvm bytecode might become a viable distribution format _ideally_ i
would like to see a llvm object file format to carry similar kind of info for
another pass of gcc/g++:

so with:
A.[h, cxx] => A.bc
B.[h, cxx] => B.bc
C.[h, cxx] => C.bc
[ABC].bc => ABC.bc

we can perform:
llvm-g++ X.cxx -I ABC.bc

without having to access the header files [ABC].h.

But since llvm's type system is meant to be lang indep the best we can do is
to make debugging info descriptive enough for future compilations, is this
correct?

It would be nice to make bc files optionally carry type info useful for another
compile pass (today bc files are only useful for linking).

Zee
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20050425/a39340dd/attachment.html>

On Mon, Apr 25, 2005 at 04:34:07AM -0500, Zeyu  Chen
wrote:
> I am asking this question to see if it is possible or desirable to
> build a compilation/runtime system for C/C++ that can support the
> following:
> 
> 1. allow bc to call native (in dynamically loaded *.so)
You can do this today, e.g., with lli -load=native.so file.bc
> 2. allow native to call bc (through JIT or interpreter)
You can also do this today as well.
> 3. can compile/interpret C/C++ sources _BASED_ on type info in
> precompiled bc
 
OK, I didn't quite understand what you meant at first, but it makes
sense with the rest of your message.  See the end of my response.
> Motivation:
[skip java-related stuff]
> Given that llvm bytecode might become a viable distribution format
> _ideally_ i would like to see a llvm object file format to carry
> similar kind of info for another pass of gcc/g++:
> 
> so with:
> A.[h, cxx] => A.bc
> B.[h, cxx] => B.bc
> C.[h, cxx] => C.bc
> [ABC].bc => ABC.bc
> 
> we can perform:
> llvm-g++ X.cxx -I ABC.bc
> 
> without having to access the header files [ABC].h.
> 
> But since llvm's type system is meant to be lang indep the best we can
> do is to make debugging info descriptive enough for future
> compilations, is this correct?
That sounds about right.  Another issue is that currently, aggressive
optimizations change the code substantially and if there were increased
debug information (which would be nice), they would have to be checked
and/or modified to be more conservative and respect the memory layout of
structures, etc.
 
> It would be nice to make bc files optionally carry type info useful
> for another compile pass (today bc files are only useful for linking).
I recon that would be a requirement to a fully-functional llvm-db
(debugger) so yes, it would be nice.  Patches are accepted. :)

-- 
Misha Brukman :: http://misha.brukman.net :: http://llvm.cs.uiuc.edu

On Mon, 25 Apr 2005, Misha Brukman wrote:
>> But since llvm's type system is meant to be lang indep the best we
can
>> do is to make debugging info descriptive enough for future
>> compilations, is this correct?
>
> That sounds about right.  Another issue is that currently, aggressive
> optimizations change the code substantially and if there were increased
> debug information (which would be nice), they would have to be checked
> and/or modified to be more conservative and respect the memory layout of
> structures, etc.
This isn't quite true.  The llvm debug info is carefully designed so that 
aggressive optimizations will automatically disable themselves when debug 
info is present (by virtue of being conservative with handling of 
incomplete programs).

-Chris

-- 
http://nondot.org/sabre/
http://llvm.cs.uiuc.edu/