<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7226.0">
<TITLE>can bc/asm carry enough type info for C/C++ compiler/interpreter?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>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:<BR>
<BR>
1. allow bc to call native (in dynamically loaded *.so)<BR>
2. allow native to call bc (through JIT or interpreter)<BR>
3. can compile/interpret C/C++ sources _BASED_ on type info in precompiled bc<BR>
<BR>
<BR>
Motivation:<BR>
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:<BR>
<BR>
A.java => A.class<BR>
B.java => B.class<BR>
C.java => C.class<BR>
[ABC].class => ABC.jar<BR>
Now compilation of any java class (X) that refs A/B/C can be done with:<BR>
javac -cp ABC.jar X.java<BR>
<BR>
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.<BR>
<BR>
For C/C++ there are 2 tools that are close to fullfilling a similar goal: gcc+gdb and cint.<BR>
<BR>
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.<BR>
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.<BR>
<BR>
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++:<BR>
<BR>
so with:<BR>
A.[h, cxx] => A.bc<BR>
B.[h, cxx] => B.bc<BR>
C.[h, cxx] => C.bc<BR>
[ABC].bc => ABC.bc<BR>
<BR>
we can perform:<BR>
llvm-g++ X.cxx -I ABC.bc<BR>
<BR>
without having to access the header files [ABC].h.<BR>
<BR>
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?<BR>
<BR>
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).<BR>
<BR>
Zee</FONT>
</P>
</BODY>
</HTML>