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 ? thanks , dane van dyck georgia institute of technology
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
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/llvmdevk 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