[LLVMdev] Fw: LLVM GC

Mon Jan 17 12:46:37 PST 2011

I've figured out why the stack trace comes from @main, and not somewhere
within my compiler's output: the output from the compiler is getting
inlined in the @main function from the runtime, thus pushing its gc
"shadow-stack" attribute out.

--trevor

On 01/16/2011 10:51 PM, Trevor Elliott wrote:
> Hi Sam,
> 
> I've not actually gotten to the linking process with my runtime, as I've
> compiled it with clang -emit-llvm -c, and then archived it with llvm-ar
> and llvm-ranlib.  I'm also not producing a GC plugin, as I'm using the
> builtin "shadow-stack" strategy.
> 
> My current build process looks like this:
> 
>  1. build the compiler
>  2. build the runtime using clang -emit-llvm -c
>  3. generate an archive from the runtime .bc files using llvm-ar and
> llvm-ranlib
>  3. compile a program with the compiler, producing a .bc file
>  4. link the program and runtime together using llvm-ld
>  5. run the program with lli
> 
> This all works fine until step 5 when the stack trace gets generated.
> The function that it complains about, @main, is the main function from
> my runtime.  When disassembled with llvm-dis, it doesn't have a gc
> attribute on the declaration.  Should it still be getting processed by
> the "shadow-stack" strategy?
> 
> Thanks!
> 
> --trevor
> 
> 
> On 01/14/2011 05:33 PM, Samuel Crow wrote:
>> 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
>>>>
>>>>
>>>
>>>
>>>       
>>>
>>
>>
>>       
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3612 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110117/6dc2317d/attachment.bin>