llvm dev - Jul 2008 - [LLVMdev] CollectorRegistry

2008/7/24 Gordon Henriksen <gordonhenriksen at
me.com>:
>> OK, so for instance if I wanted to be able to use the GC from a C
>> frontend (presumably by using llvm_gc_allocate?), do the C functions
>> need this attribute as well?
>
> Yes.
I forgot I still needed an answer to my original question. :-P

So, I have to implement llvm_gc_initialize, llvm_gc_allocate, and
llvm_gc_collect (llvm_cg_walk_gcroots is provided by the Collector
framework, right?) -- in those methods, how do I access the Collector
object instantiated by LLVM?

(It appears I do have to implement them myself, since otherwise there
are unresolved symbols when I call them directly from my IR)

- Simon

On Jul 26, 2008, at 10:32, Simon Ask Ulsnes wrote:
> I forgot I still needed an answer to my original question. :-P
>
> So, I have to implement llvm_gc_initialize, llvm_gc_allocate, and  
> llvm_gc_collect
Yes. Your implementation of the llvm_gc_* functions should be compiled  
into a library and linked with your executable.
> (llvm_cg_walk_gcroots is provided by the Collector framework, right?)
An implementation of llvm_cg_walk_gcroots compatible with  
ShadowStackCollector is provided in the llvm/runtime directory. You  
can copy it into your runtime.
> in those methods, how do I access the Collector object instantiated  
> by LLVM?
I'm not sure the purpose of doing so—llvm::Collector (poorly named;  
I'm open to suggestions) exists only in the compiler, not at runtime  
in the compiled program. You should need access to it at runtime no  
more than you might need access to an instance of llvm::TargetMachine.

— Gordon

2008/7/26 Gordon Henriksen <gordonhenriksen at
me.com>:
> I'm not sure the purpose of doing so—llvm::Collector (poorly named;
> I'm open to suggestions) exists only in the compiler, not at runtime
> in the compiled program. You should need access to it at runtime no
> more than you might need access to an instance of llvm::TargetMachine.
Maybe I don't understand the architecture correctly.

This means that the implementation of my collector's data structures
(in this case, a few heaps) is supposed to be independent on the
subclassed llvm::Collector?

I had initially implemented it as

class SimonCollector : public llvm::Collector
{
    public:
        // ... virtual methods from llvm::Collector

        void* allocate(...) { /* my allocator */ }
        void collect() { /* ... */ }
        // etc.
};

but actually allocate, collect, etc. aren't supposed to be there, but
in some separate structure that is accessed by both my llvm::Collector
subclass (or rather, the assembly generated in the lowering passes)
and llvm_gc_*?

If that is the case, then I agree, it's a poor name -- at least it got
me confused. :-P
It's hard to come up with good alternatives, though. Hmm.

I looked a bit at the ShadowStackCollector class, and suddenly it
makes much more sense. But I fail to find any implementations of
llvm_gc_allocate and friends?

- Simon