[LLVMdev] Fw: LLVM GC

[Samuel Crow]

Forgot to CC the list.


----- Forwarded Message ----
> From: Samuel Crow <samuraileumas at yahoo.com>
> To: Trevor Elliott <trevor at galois.com>
> Sent: Fri, January 14, 2011 7:33:15 PM
> Subject: Re: [LLVMdev] LLVM GC
> 
> Hi Trevor,
> 
> Are you linking with LibStdC++ or LibC++?  That is a  requirement for running 
> code that has been compiled from C++ to  bitcode.
> 
> Hope this helps,
> 
> --Sam Crow
> 
> 
> ----- Original  Message ----
> > From: Trevor Elliott <trevor at galois.com>
> > To: llvmdev at cs.uiuc.edu
> > Sent: Fri,  January 14, 2011 7:17:30 PM
> > Subject: [LLVMdev] LLVM GC
> > 
> >  Hi,
> > 
> > I've been implementing a compiler that targets LLVM, and  was  looking
> > into using the shadow-stack gc strategy.   Currently, I build the  runtime
> > with clang (using -emit-llvm), and  then link that with the LLVM  bitcode
> > output from my compiler using  llvm-ld.
> > 
> > This works fine without  the gc strategy  annotations and use of the
> > llvm.gcroot intrinsic, but adding  them  causes some odd behavior: the
> > resulting bitcode will generate a  large  stack trace from lli (appended
> > at the end of this message),  and the resulting  native assembly,
> > generated with llc, will never  update my llvm_gc_root_chain  global.
> > 
> > Interestingly, if I  build my runtime with g++, or clang  without
> > -emit-llvm, and link  everything together after generating  native
> > assembly from the  output of my compiler, it works.  The stack  roots get
> >  registered, and the llvm_gc_root_chain global gets  updated.
> > 
> > Is linking in the runtime as an LLVM bitcode object something   that I
> > should expect to work, or does it make more sense to build  the  runtime
> > for the target, and not try to emit LLVM bitcode  programs from my  
compiler?
> > 
> > Thanks!
> > 
> >  --trevor
> > 
> > 
> > 0  libLLVM-2.8.so    0x0000003cc36eee9f
> > 1  libLLVM-2.8.so   0x0000003cc36ef99a
> > 2  libpthread.so.0  0x0000003cc200f4a0
> >  3  libLLVM-2.8.so   0x0000003cc33360dd
> >  llvm::StructType::StructType(llvm::LLVMContext&,   std::vector<llvm::Type
> > const*, std::allocator<llvm::Type  const*>  > const&, bool) + 237
> > 4   libLLVM-2.8.so   0x0000003cc3337c95
> >  llvm::StructType::get(llvm::LLVMContext&,  std::vector<llvm::Type  const*,
> > std::allocator<llvm::Type const*>  > const&,  bool) + 533
> > 5  libLLVM-2.8.so   0x0000003cc3242d58
> >  6  libLLVM-2.8.so  0x0000003cc318f09e
> > 7    libLLVM-2.8.so   0x0000003cc3330628
> >  llvm::FPPassManager::runOnFunction(llvm::Function&) +  424
> >  8  libLLVM-2.8.so   0x0000003cc33307cb
> >  llvm::FunctionPassManagerImpl::run(llvm::Function&) +  91
> >  9  libLLVM-2.8.so   0x0000003cc33309bd
> >  llvm::FunctionPassManager::run(llvm::Function&) +  173
> > 10  libLLVM-2.8.so   0x0000003cc33e8647
> >  llvm::JIT::jitTheFunction(llvm::Function*,  llvm::MutexGuard const&) +  39
> > 11 libLLVM-2.8.so   0x0000003cc33e8a2f
> >  llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*,   llvm::MutexGuard
> > const&) + 15
> > 12 libLLVM-2.8.so    0x0000003cc33e8cde
> > llvm::JIT::getPointerToFunction(llvm::Function*)  +  606
> > 13 libLLVM-2.8.so   0x0000003cc33ea253
> >  llvm::JIT::runFunction(llvm::Function*,   std::vector<llvm::GenericValue,
> >  std::allocator<llvm::GenericValue>  > const&) + 67
> > 14  libLLVM-2.8.so   0x0000003cc336ad4a
> >  llvm::ExecutionEngine::runFunctionAsMain(llvm::Function*,
> >  std::vector<std::string,  std::allocator<std::string> >  const&, char
> > const* const*) +  1130
> > 15 lli              0x0000000000404cd6 main  + 2054
> > 16 libc.so.6         0x0000003cc1c1ec5d __libc_start_main + 253
> > 17 lli               0x0000000000403689
> > Stack dump:
> >  0.     Program arguments: lli test.bc
> > 1.    Running  pass 'Lower  Garbage Collection Instructions' on function 
> '@main'
> > zsh: segmentation fault  (core dumped)   ./test
> > 
> > 
> 
> 
>       
>