[LLVMdev] tracing stack variables

[Dane Napier van Dyck]

Gordon Henriksen wrote:
> On 2008-09-16, at 19:01, Dane Napier van Dyck wrote:
> 
>> 	I'm trying to discern whether or not stack variables are all  
>> accessible through ExecutionEngine.cpp .
>> 	Initially , I targeted the 'alloca' function as the source for all  
>> stack accession data , but I think that the function is too basic :  
>> ie , the type data may not be easily accessible from that function's  
>> scope .
>> 	So my next idea was to use ExecutionEngine , because when data is  
>> allocated the information I want is already being used to determine  
>> allocation space . But I'm don't think stack accessions are included  
>> in its scope . I do need global (and static) info but I'm confident  
>> everything I need is here .
>> 	I'm still interested in using XNgine::LoadFromMemory to access my  
>> stack variables but I wonder what someone more experienced would  
>> do ; Will this cover all of the bases ? ; Can I reference metadata  
>> at (or near) the pointer returned by 'alloca' to get the info I need ?
> 
> 
> Doesn't sound like you're on the right track. What are you attempting  
> to do? GC and debugger spring to mind.
> 
> If you're doing garbage collection (tracing stack roots), then the  
> shadow stack GC should work equally with the interpreter or the JIT.  
> Slightly more sophisticated and performant GC can be implemented for  
> statically compiled code by implementing a GCStrategy subclass and  
> combining static stack frame metadata with an unwinding runtime to  
> walk the machine stack. http://llvm.org/docs/GarbageCollection.html
> 
> If you're attempting to inspect the stack as in a debugger, you'll  
> have to use debug information (like gdb does); LLVM can aggressively  
> promote to registers and eliminate stack slots, so your allocas could  
> cease to exist. There may be libraries you can use for this; maybe  
> someone else will chime in.
> 
> — Gordon
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
k Gordon ,

	I'm going to proceed with the debugger library . I don't think I'll 
instantiate a complete debugger tho , hopefully I can select a partner 
class without as much overhead . I'm going to look around to see if 
there is a notification available for stack changes .

dane