search for: llvm_gc_root_chain

...# @main # BB#0: # %entry subl $12, %esp movl $6, (%esp) call malloc movl %eax, 8(%esp) xorl %eax, %eax addl $12, %esp ret .size main, .-main .type llvm_gc_root_chain, at object .section .gnu.linkonce.b.llvm_gc_root_chain,"aw", at nobits .comm llvm_gc_root_chain,4,4 # @llvm_gc_root_chain .section .note.GNU-stack,"", at progbits Any clues? This is on 32-bit x86, linux with binutils 2.18. Regards, Pa...

...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_roo...

...ine 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...

...>> 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 t...

The linker is going off in the weeds trying to parse the dwarf unwind info. The CIE has: Leh_frame_common_begin0: .long 0 ## CIE Identifier Tag .byte 1 ## DW_CIE_VERSION .asciz "zLR" ## CIE Augmentation .byte 1 ## CIE Code Alignment Factor .byte 120 ## CIE Data Alignment

Hi, If I type define i32 @main() gc "shadow-stack" { entry: %0 = alloca i8* %1 = call i8* @malloc(i64 1) store i8* %1, i8** %0 call void @llvm.gcroot(i8** %0, i8* null) ret i32 0 } declare i8* @malloc(i64) declare void @llvm.gcroot(i8**, i8*) nounwind in test.ll and then do > llc test.ll > gcc test.s I get the error ld: in

Ok, I *might* be getting this from the assembly code. The assembly code has: L_llvm_gc_root_chain$non_lazy_ptr: .indirect_symbol _llvm_gc_root_chain .long 0 and I see it being used in the function preamble. Is that a ref to an extern symbol or the def? I.e., is it referring to StackEntry *llvm_gc_root_chain; that I must have in my GC C code? (semispace.c has it) SO!...

This is an interesting problem. The GC code is being converted into 'invokes' instead of calls: define i32 @main() gc "shadow-stack" { entry: %gc_frame = alloca %gc_stackentry.main %gc_currhead = load %gc_stackentry** @llvm_gc_root_chain %gc_frame.map = getelementptr %gc_stackentry.main* %gc_frame, i32 0, i32 0, i32 1 store %gc_map* getelementptr inbounds (%gc_map.0* @__gc_main, i32 0, i32 0), %gc_map** %gc_frame.map %0 = getelementptr %gc_stackentry.main* %gc_frame, i32 0, i32 1 store i8* null, i8** %0 %gc_frame.next = g...

...inters that are out of scope from those that aren't, so this lets it > consider all pointers to be in scope, without causing any "dead" pointers > to mark objects. Does this mean some pointers from the roots might be null? I figured only in-scope variables/roots would be in the llvm_gc_root_chain. Does this list ever shorten? > I would suggest doing experiments to determine which has the higher > overhead. Refcounting as a whole is expensive, so you need to find a > design that fits your constraints/application. I don't actually have an application at the moment; I'm jus...

Again, sorry for the delay. :( On Thu, 9 Mar 2006, Sandro Magi wrote: > I've written a reference-counting garbage collector for LLVM, but I'm > still unclear on a few things. Cool! > The following piece of code that appears on > http://llvm.cs.uiuc.edu/docs/GarbageCollection.html is unclear: > > ;; As the pointer goes out of scope, store a null value into > ;;

Hello, I've spent some time with the LLVM documentation and am beginning to grasp a few things, but I sometimes need very literal statements to actually understand things. My first question is about StackMaps: Is it true that llvm_gc_root_chain is an API? I've been trying to understand how exactly one accesses this structure and no where in the documentation does it mention this is a public variable that will be present in the final executable (in those or such explicit words). Secondly, if this is true, does it then mean that this va...

Hi Everyone, I've managed to create a small example that reproduces the error that I'm seeing when generating code, or running the interpreter: ----------------------------------------------------------------------- @llvm_gc_root_chain = global i8* null declare i8* @malloc(i32) declare void @llvm.gcroot(i8**, i8*) nounwind define i32 @main() gc "shadow-stack" { %value = call i8* @malloc(i32 32) %ptr = alloca i8* store i8* %value, i8** %ptr call void @llvm.gcroot(i8** %ptr, i8* null) ret i32 0 } ---------...

...hout causing any "dead" pointers >> to mark objects. > > Does this mean some pointers from the roots might be null? Well sure, if they are null. e.g.: int *X = NULL; X would be null. Is that what you mean? > I figured > only in-scope variables/roots would be in the llvm_gc_root_chain. That is correct, "global" roots have to be managed separately. > Does this list ever shorten? It changes dynamically based on what functions are currently live. >> I would suggest doing experiments to determine which has the higher >> overhead. Refcounting as a whole...

...aration of 'Map' semispace.c:108: warning: data definition has no type or storage class semispace.c:110: error: syntax error before '}' token semispace.c:111: error: syntax error before '*' token semispace.c:111: warning: type defaults to 'int' in declaration of 'llvm_gc_root_chain' semispace.c:111: warning: data definition has no type or storage class semispace.c: In function 'llvm_cg_walk_gcroots': semispace.c:114: error: 'StackEntry' undeclared (first use in this function) semispace.c:114: error: (Each undeclared identifier is reported only once semispa...

On Apr 21, 2008, at 20:09, Terence Parr wrote: > Ok, I *might* be getting this from the assembly code. ... From > that, it will push/pop in functions? If so, that's easy enough. :) Yup! Sounds like you've got it. > What I was/am missing is the explicit link between types and > variables in a GC.c file and the generated machine code. If I can > get that last

..., it will push/pop in functions? If so, that's easy enough. :) > > Yup! Sounds like you've got it. Yup, what i was missing and what somebody should add to the doc is that "shadow-stack" adds a preamble/postamble snippet to each function that must bind with StackEntry *llvm_gc_root_chain; wherever you choose to define it. I put into my GC.c file. Further, that shadow-stack snippet generation assumes the following structures for tracking roots: typedef struct FrameMap FrameMap; struct FrameMap { int32_t NumRoots; // Number of roots in stack frame. int32_t NumMeta; // Nu...

...so, that's easy enough. :) >> >> Yup! Sounds like you've got it. > > Yup, what i was missing and what somebody should add to the doc is > that "shadow-stack" adds a preamble/postamble snippet to each > function that must bind with > > StackEntry *llvm_gc_root_chain; > > wherever you choose to define it. I put into my GC.c file. > > Further, that shadow-stack snippet generation assumes the following > structures for tracking roots: > > typedef struct FrameMap FrameMap; > struct FrameMap { > int32_t NumRoots; // Number of roots i...