[LLVMdev] accessing a bitcode library exported from C++ using the JIT

[Samuel Crow]

----- Original Message ----
> From: Eli Friedman <eli.friedman at gmail.com>
> To: Samuel Crow <samuraileumas at yahoo.com>
> Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Sent: Monday, August 31, 2009 3:49:01 PM
> Subject: Re: [LLVMdev] accessing a bitcode library exported from C++ using the  JIT
> 
> On Mon, Aug 31, 2009 at 12:17 PM, Samuel Crowwrote:
> > Hello,
> >
> > My partner and I am making a small app needs to access a C++ library from the 
> LLVM 2.5 JIT.  We've made sure that there are no classes and have put 'extern 
> "c"' in front of the functions we need to access.  In order to make this work, 
> we seem to need to have a bitcode version of libstdc++ so we can avoid writing 
> our own implementations of std::string and std::vector.  I've been trying to get 
> the version of libstdc++ that came with llvm-gcc-4.2-2.5 to configure and 
> compile.  I've set the environment variables to use llvm-gcc and llvm-g++ 
> respectively and placed the --emit-llvm flag in the CCFLAGS and CXXFLAGS 
> environment variables.  Configure works but make fails with:
> >
> > from 
> /Users/samuraicrow/Documents/llvm-gcc4.2-2.5.source/libstdc++-v3/include/precompiled/extc++.h:60:
> > 
> /Users/samuraicrow/Documents/llvm-gcc4.2-2.5.source/libstdc++-v3/include/ext/pb_ds/detail/priority_queue_base_dispatch.hpp:79: 
> error: ISO C++ forbids declaration of ‘rc_binomial_heap_’ with no type
> > 
> /Users/samuraicrow/Documents/llvm-gcc4.2-2.5.source/libstdc++-v3/include/ext/pb_ds/detail/priority_queue_base_dispatch.hpp:79: 
> error: expected ‘;’ before ‘<’ token
> >
> > I'm building on MacOSX 10.5.8 and my parnter will be building on MinGW under 
> Windows XP.
> >
> > Is this a problem with the source or with my configuration?  Has this been 
> solved in version 2.6 prerelease or ToT?
> 
> It's probably a problem with your configuration, since llvm-gcc can
> definitely build libstdc++ as part of the normal build.
> 
> This seems like the wrong approach, though... can't you just make your
> C APIs take char*/T* instead?
> 
> -Eli

Hello Eli,

We're using the LLVM Value * class functions to box and unbox values and functions for our stack.  The stack needs to be able to take indexing without changing the stack pointer so we're using a std::vector for that.  The std::string section would be a lot easier to replace than the two I just mentioned since we store the length separately.

This library is serving as part of an interpreted parser generator so it needs to be able to handle all types and functions that we choose to feed into it.  For now it is i32, Float and String and in the future, Doubles and functions of various sorts need to go onto the stack.  The only thing I doubt about our approach is that we might be able to get away with using an interpreter instead of a JIT since the code is fed through the LLVM assembly parser just as it gets executed.

If you're wondering why we're doing an interpreted PEG parser generator rather than Boost Spirit 2.x, it's because we need it to be easier to debug the parser.  Once the parser is debugged it can be fed into a compiled parser generator and "frozen" into stand-alone parser code.

--Sam