stack frame optimization problem

sprucely timberdig at gmail.com
Sat Oct 24 17:22:50 PDT 2009


I've been able to determine that the trick, extern(C) byte jumpHere, is not providing the correct address. Since all my functions will have an identical stack frame, it will be easy enough to just hard code the proper offset.

sprucely Wrote:

> Okay, between gdb and obj2asm I've been able to figure out that the address placed in EAX in the following instructions...
> 
> 		mov EAX, jumpTo;
> 		jmp EAX;
> 
> is actually the address of the initialization function for jumpTo... 
> 
> byte* jumpTo = &jumpHere;
> 
> which is named _D9conductor6jumpToPg. Execution then ends up segfaulting on a (bad) instruction in function _moduleinfo_array.
> 
> So I'm not sure if the wrong address is being stored in jumpTo or if I'm simply not correctly dereferencing it. Ultimately I need to know the offset from function pointers to the point at which the prolog has completed and execution of the main function body begins. I'm attempting to discover the offset by using a dummy function containing a "jumpHere:" label and subtracting the function address from the label address. Is there a better way to do this?
> 
> Thanks for the suggestions I've received. I'm learning a lot!
> 
> 
> sprucely Wrote:
> 
> > This works with g++ and inline ATT assembly, but I have had no such luck in D. I have many simple functions that need to be executed sequentially and have identical stack frames. To avoid the overhead of setting up and tearing down the stack frames I want to jmp from the body of one function to the body of the next. A simplified example...
> > 
> > extern(C) byte jumpHere;
> > 
> > byte* jumpTo = &jumpHere;
> > 
> > void f1()
> > {
> > 	asm
> > 	{
> > 		//jmp dword ptr jumpTo;
> > 		mov EAX, jumpTo;
> > 		jmp EAX;
> > 		//jmp [EAX]
> > 	}
> > }
> > 
> > void f2()
> > {
> > 	asm{jumpHere:;}
> > }
> > 
> > No matter what I try I get a segfault. My assembly skills are very limited. I'm not using the naked keyword yet, because I want to get a proof-of-concept working first. Anyone see anything wrong with this? Any suggestions?
> 




More information about the Digitalmars-d mailing list