[LLVMdev] tracing stack variables

Gordon Henriksen gordonhenriksen at me.com
Tue Sep 16 16:45:34 PDT 2008


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





More information about the llvm-dev mailing list