search for: semispace

I just downloaded the source for release 2.2, and when I try to build 'make -C runtime' it fails with the following error: ---- [...] llvm[2]: Compiling semispace.c for Release build (bytecode) semispace.c:107: error: syntax error before 'ShadowStackEntry' semispace.c:107: warning: no semicolon at end of struct or union semispace.c:108: error: syntax error before '*' token semispace.c:108: warning: type defaults to 'int' in declaratio...

...ling, reading, playing, looking at source). I can't find > the shadow collector lib or perhaps the -l options needed to link my > sample (not even to point where I'm figuring out GC actually as I > can't link). The shadow stack walker is in the runtime directory with the semispace heap example. The runtime directory is built to LLVM IR using llvm- gcc. So it's skipped unless you configure llvm with llvm-gcc support. Since the semispace heap doesn't actually work (it's an example, at best), I suggest you simply copy the stack visitor into your project; it&...

Howdy do LLVM folks! I've exhausted what I can do on my own to make a GC example bind (usual googling, reading, playing, looking at source). I can't find the shadow collector lib or perhaps the -l options needed to link my sample (not even to point where I'm figuring out GC actually as I can't link). Not sure this IR is correct but here is what I've been playing

On Apr 20, 2008, at 5:36 PM, Gordon Henriksen wrote: > The shadow stack walker is in the runtime directory with the semispace > heap example. The runtime directory is built to LLVM IR using llvm- > gcc. So it's skipped unless you configure llvm with llvm-gcc support. doh! That's how I missed the binary. thanks! > Since the semispace heap doesn't actually work (it's an example, at > best), I...

...t; How should we get this to run? > > Sorry about that, patch for this problem here: > http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041025/019891.html That patch does fix the problem. Thank you. I used the following llvm-link -f -o linked.bc alloc_loop.bc ~/llvm/runtime/GC/SemiSpace/Debug/semispace.bc because it seemed easier than working out if and how to get dynamic loading and linking to work. Perhaps the process will be smoother when I restart using projects/sample/ . Running linked.bc outputs Garbage collecting!! process_root[0x0xbffff3f0] = 0x0x41257008 process_root[0x0...

I'm in a group tasked with improving the GC of LLVM for a 421 project. We are having trouble getting started with the given SemiSpace collector. We found the string llvm_gc_initialize called from a single source file ./test/Regression/CodeGen/Generic/GC/alloc_loop.ll which we tried with the following... (showing LLVM checked out from cvs a few days ago, similar output with release 1.3) $ llvm-as alloc_loop.ll $ lli alloc_loop....

On Tue, 26 Oct 2004, Tom Brown wrote: > I'm in a group tasked with improving the GC of LLVM for a 421 project. > We are having trouble getting started with the given SemiSpace > collector. > > We found the string llvm_gc_initialize called from a single source file > ./test/Regression/CodeGen/Generic/GC/alloc_loop.ll > which we tried with the following... (showing LLVM checked out from cvs a few days ago, similar > output with release 1.3) > > $ l...

...s to run? > > > > Sorry about that, patch for this problem here: > > http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041025/019891.html > That patch does fix the problem. Thank you. I used the following > llvm-link -f -o linked.bc alloc_loop.bc ~/llvm/runtime/GC/SemiSpace/Debug/semispace.bc > because it seemed easier than working out if and how to get dynamic > loading and linking to work. Perhaps the process will be smoother when > I restart using projects/sample/. Okay, sounds good. Running linked.bc outputs > Garbage collecting!! > process_root[...

...**FieldPtr) I haven't seen an adequate explanation of these, but I'm guessing: void *V: value being written to the field void *ObjPtr: current value of the field (ie. ObjPtr == *FieldPtr upon entry to llvm_gc_write) void **FieldPtr: address of the field being written 2. The current semispace collector includes some code which says it should be in a code-generator library. If I were to write a collector, should I also include this code for the time being? Or will this soon be refactored into an external interface? 3. void %llvm.gcroot(<ty>** %ptrloc, <ty2>* %metadata) I do...

Hi, This is regarding the backend for garbage collection. My problem might be related to some strange memory fault created by my frontend, but I'll try here to get some feedback. For some strange reason I get segmentation fault in process_pointer in semispace.c (I've implemented a small collector, hopefully :). The fault occurs when I do: printf("process_root[0x%p] = 0x%p\n", (void*) Root, (void*) *Root); I.e, when I reference Root. My frontend creates llvm assembly with llvm-gcroot in the following manner: ... %r22 = alloca uint ;;...

...gt;Field = Ptr; you'd want to compile it as: llvm_gc_write(Ptr, Obj, &Obj->Field); This is used by the GC if it keeps bits in the object header or other things. If the GC you plan to use doesn't need this info, you don't need to provide it obviously. :) > 2. The current semispace collector includes some code which says it > should be in a code-generator library. If I were to write a collector, > should I also include this code for the time being? Yes, I would suggest including it. > Or will this soon be refactored into an external interface? Right now, noone is...

...config.log ? llvm/projects/sample/config.status ? llvm/projects/sample/lib/Debug ? llvm/projects/sample/lib/sample/Debug ? llvm/projects/sample/lib/sample/Depend ? llvm/projects/sample/tools/Debug ? llvm/projects/sample/tools/sample/Debug ? llvm/projects/sample/tools/sample/Depend ? llvm/runtime/GC/SemiSpace/BytecodeObj ? llvm/runtime/GC/SemiSpace/Debug ? llvm/runtime/GC/SemiSpace/Depend ? llvm/runtime/GCCLibraries/crtend/BytecodeObj ? llvm/runtime/GCCLibraries/crtend/Depend ? llvm/runtime/GCCLibraries/libc/BytecodeObj ? llvm/runtime/GCCLibraries/libc/Depend ? llvm/runtime/GCCLibraries/libcurses/Byteco...

Hi, I'm trying to instrument llvm bytecodes using opt. I performed the following commands: llvm-gcc -g -emit-llvm test.c -c -o test.bc opt -insert-edge-profiling test.bc -o output.bc llc output.bc -o output.s gcc output.s -o test.out However, it can't find symbol llvm_start_edge_profiling. /tmp/ccw7GH4c.o: In function `main': /home/raul/LLVM/tests//test.c:8: undefined reference

Hi, > llvm-gcc -g -emit-llvm test.c -c -o test.bc > opt -insert-edge-profiling test.bc -o output.bc > llc output.bc -o output.s > gcc output.s -o test.out > > However, it can't find symbol llvm_start_edge_profiling. -insert-edge-profiling inserts call to the llvm_start_edge_profiling function which is a part of a profiling runtime library. This library must be linked

On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > Hi, I'm thinking out loud, please give me some feedback. > > Regarding llvm.gcread and llvm.gcwrite, wouldn't it be nicer if they are > implemented as: > > llvm.gcread(sbyte** object, uint offset) > llvm.gcwrite(sbyte* data, sbyte** object, uint offset) > > Where you also have the offset into the object. In

...t obviously. :) Makes sense. A few more questions: 1. Any generic LLVM GC must be customised for a given front-end, correct? In other words, it requires front-end information regarding the layout of pointers within a block in order to fully trace the reference graph. Or am I missing something? Is semispace a drop-in for any front-end that utilizes the llvm.gc* intrinsics? 1a. Semispace isn't actually complete/working is it? Its llvm_gc_collect() implementation doesn't actually seem to do anything, ie. no copying, no space switching, etc. :-) 2. Are there any GC tests available that I can...

We have a few questions about the current state of GC. We decided to start (and finish?) our work by finishing SemiSpace. process_pointer is meant to move objects from CurSpace to OtherSpace. How can it find pointers to a moved object? How does it know the size of each object? Assuming we are writing a GC that will only work from llvm assembly our best option seems to be forcing the assembly code to follow a conventi...

...ns from looking at the source code of the GCStrategy class, but I like to see an example for my own code to see what is really happening. The llvm specific cpp code is hard to understand because im not really a llvm framework developer. Another question, the GC tutorial refers to "/runtime/GC/SemiSpace/semispace.cpp" (a simple gc on top of the shadow-stack) but this file does not exist in the 2.6 release, I was able to find it in older releases. Is it out-dated? will there be an example garbage collector in the 2.7 release? Are there any other code examples of garbage collectors written on...

Ok, that makes sense :). , Tobias On Wed, 21 Jul 2004, Chris Lattner wrote: > On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { > > > return *FieldPtr; > > > } > > > > Hm, but doesn't FieldPtr need to be calculated target-specific in those > > cases? > > For the field pointer, one

...**FieldPtr) I haven't seen an adequate explanation of these, but I'm guessing: void *V: value being written to the field void *ObjPtr: current value of the field (ie. ObjPtr == *FieldPtr upon entry to llvm_gc_write) void **FieldPtr: address of the field being written 2. The current semispace collector includes some code which says it should be in a code-generator library. If I were to write a collector, should I also include this code for the time being? Or will this soon be refactored into an external interface? 3. void %llvm.gcroot(<ty>** %ptrloc, <ty2>* %metadata) I do...