[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