开发者

a "general function signature" pointer that points to an arbitrary function

I'll try to explain better what I want to do. I read a file with function signatures, and I want to create a pointer to each function.

For example, a file that looks like this:

something.dll;int  f(char* x, int y, SOMESTRUCT z)
something.dll;void g(void)
something.dll;SOMESTRUCT l(longlong w)

now, during runtime I want be able to create pointers to these functions (by loading something.dll and using GetProcAddress to these functions).

Now, GetProcAddress returns 开发者_StackOverflowFARPROC which points to an arbitrary functions, but how can I use FARPROC to call these functions during runtime? From what I know, I need to cast FARPROC to the correct signature, but I can't do it during runtime (or at least I don't know how).

Does anyone have any idea how to design do that?

Thanks! :-)


  1. Function types are compile-time in C++, so it won't work, unless you can define all the types you're going to use in advance.

  2. Its a matter of pushing the arguments to the stack (and local vars are like that) and calling the function as void (__cdecl *)(void).

  3. With some other kinds of functions (like fastcall, or thiscall) it can be more problematic.

Update: I actually made an example, and it works on codepad: (Also works with stdcall functions, because of stack restore after aligned stack alloc)

http://codepad.org/0cf0YFRH

#include <stdio.h>

#ifdef __GNUC__
 #define NOINLINE __attribute__((noinline))
 #define ALIGN(n) __attribute__((aligned(n)))
#else
 #define NOINLINE __declspec(noinline)
 #define ALIGN(n) __declspec(align(n))
#endif

//#define __cdecl

// Have to be declared __cdecl when its available, 
// because some args may be passed in registers otherwise (optimization!)
void __cdecl test( int a, void* b ) {
  printf( "a=%08X b=%08X\n", a, unsigned(b) );
}

// actual pointer type to use for function calls
typedef int (__cdecl *pfunc)( void );

// wrapper type to get around codepad's "ISO C++" ideas and gcc being too smart
union funcwrap { 
  volatile void* y; 
  volatile pfunc f; 
  void (__cdecl *z)(int, void*);
};

// gcc optimization workaround - can't allow it to know the value at compile time
volatile void* tmp = (void*)printf("\n");
volatile funcwrap x; 
int r;

// noinline function to force the compiler to allocate stuff 
// on stack just before the function call
NOINLINE
void call(void) {
  // force the runtime stack pointer calculation
  // (compiler can't align a function stack in compile time)
  // otherwise, again, it gets optimized too hard

  // the number of arguments; can be probably done with alloca()
  ALIGN(32) volatile int a[2]; 
  a[0] = 1; a[1] = 2; // set the argument values
  tmp = a; // tell compiler to not optimize away the array
  r = x.f(); // call the function; returned value is passed in a register

  // this function can't use any other local vars, because
  // compiler might mess up the order
}

int main( void ) {
  // again, weird stuff to confuse compiler, so that it won't discard stuff
  x.z = test; tmp=x.y; x.y=tmp;
  // call the function via "test" pointer
  call();
  // print the return value (although it didn't have one)
  printf( "r=%i\n", r );
}


Once you have a FARPROC, you can cast the FARPROC into a pointer to the appropriate function type. For example, you could say

int (*fPtr)(char*, int, SOMESTRUCT) = (int (*)(char*, int, SOMESTRUCT))GetProcAddress("f");

Or, if you want to use typedefs to make this easier:

typedef int (*FType)(char *, int, SOMESTRUCT);
FType fPtr = (FType)GetProcAddress("f");

Now that you have the function pointer stored in a function pointer of the appropriate type, you can call f by writing

fPtr("My string!", 137, someStructInstance);

Hope this helps!


The compiler needs to know the exact function signature in order to create the proper setup and teardown for the call. There's no easy way to fake it - every signature you read from the file will need a corresponding compile-time signature to match against.

You might be able to do what you want with intimate knowledge of your compiler and some assembler, but I'd recommend against it.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜