On Tue, Oct 26, 2004 at 11:17:00PM -0500, Chris Lattner wrote:> On Tue, 26 Oct 2004, Tom Brown wrote: > > $ llvm-as alloc_loop.ll > > $ lli alloc_loop.bc > > lli: Globals.cpp:81: llvm::GlobalVariable::GlobalVariable(const llvm::Type*, bool, llvm::GlobalValue::LinkageTypes, llvm::Constant*, const std::string&, llvm::Module*): Assertion `Initializer->getType() == Ty && "Initializer should be the same type as the GlobalVariable!"' failed. > > lli((anonymous namespace)::PrintStackTrace()+0x1a)[0x857f21a] > > lli((anonymous namespace)::SignalHandler(int)+0xcb)[0x857f48d] > > [0xffffe420] > > 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.htmlThat 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[0x0xbffff3ec] = 0x0x41257012 lli((anonymous namespace)::PrintStackTrace()+0x1a)[0x857f236] lli((anonymous namespace)::SignalHandler(int)+0xcb)[0x857f4a9] [0xffffe420] lli(llvm::ExecutionEngine::runFunctionAsMain... Which is too be expected since llvm_gc_collect in llvm/runtime/GC/SemiSpace/semispace.c ends with abort(); I believe we have our work cut out for us. Hopefully you'll have a working GC by Christmas time. Tom -- 28 70 20 71 2C 65 29 61 9C B1 36 3D D4 69 CE 62 4A 22 8B 0E DC 3E mailto:tdbrown at uiuc.edu http://thecap.org/
On Wed, 27 Oct 2004, Tom Brown wrote:> On Tue, Oct 26, 2004 at 11:17:00PM -0500, Chris Lattner wrote: > > On Tue, 26 Oct 2004, Tom Brown wrote: > > > $ llvm-as alloc_loop.ll > > > $ lli alloc_loop.bc > > > lli: Globals.cpp:81: llvm::GlobalVariable::GlobalVariable(const llvm::Type*, bool, llvm::GlobalValue::LinkageTypes, llvm::Constant*, const std::string&, llvm::Module*): Assertion `Initializer->getType() == Ty && "Initializer should be the same type as the GlobalVariable!"' failed. > > > lli((anonymous namespace)::PrintStackTrace()+0x1a)[0x857f21a] > > > lli((anonymous namespace)::SignalHandler(int)+0xcb)[0x857f48d] > > > [0xffffe420] > > > 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/.Okay, sounds good. Running linked.bc outputs> Garbage collecting!! > process_root[0x0xbffff3f0] = 0x0x41257008 > process_root[0x0xbffff3ec] = 0x0x41257012 > lli(llvm::ExecutionEngine::runFunctionAsMain... > > Which is too be expected since llvm_gc_collect in > llvm/runtime/GC/SemiSpace/semispace.c ends with abort();> I believe we have our work cut out for us. Hopefully you'll have a > working GC by Christmas time.Yes, indeed :) That would be great! Thanks! :) -Chris -- http://llvm.org/ http://nondot.org/sabre/
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 convention that identifies pointers. The SemiSpace code could keep a map from each allocated pointer to its size, similar to how I think malloc works. http://llvm.cs.uiuc.edu/docs/GarbageCollection.html (Which seems to be the inverse of out-of-date, whatever that is) Says that there is strong dependency between the frontend and GC implementations. For example, it seems as though the frontend and GC need to agree on a structure for the Meta data and they may call each other during allocation and garbage collection. I imagine it would be good to decouple the frontend and GC as much as possible or one may need to be reimplemented when the other is changed. Do you have any intentions for the use of Meta in SemiSpace? We could trample around and make something work but it seems as though you have built most of the support structure for GC. We are trying to follow that plan. Tom -- 28 70 20 71 2C 65 29 61 9C B1 36 3D D4 69 CE 62 4A 22 8B 0E DC 3E mailto:tdbrown at uiuc.edu http://thecap.org/