Get address of function, not entry in jump table.

[Todd A. Anderson]

I have a function foo of which I need to get the address. The problem
is that when you say "&foo" (or just foo for that matter), you get the
address of this function's entry in a jump table and not the address of
the function itself. Are there any BKMs for getting the real address or
am I going to have to write a function that looks to see whether the
address is a jump instruction and if so compute the real address from
the jump target?

thanks,

Todd

 

[Victor Bazarov]

I have a function foo of which I need to get the address. The problem
is that when you say "&foo" (or just foo for that matter), you get the
address of this function's entry in a jump table and not the address
of the function itself. Are there any BKMs for getting the real
address or am I going to have to write a function that looks to see
whether the address is a jump instruction and if so compute the real
address from the jump target?

In C++ terms, when you say 'foo', you get a pointer to the function that
you can use to call it or compare it for equality with another pointer.
There is no other use for it. What would be your definition of the "real
address" and what are you going to do with it? Most likely, there is no
solution to your problem in terms of standard C++.

V

 

[Todd A. Anderson]

In C++ terms, when you say 'foo', you get a pointer to the function that
you can use to call it or compare it for equality with another pointer.
There is no other use for it. What would be your definition of the "real
address" and what are you going to do with it? Most likely, there is no
solution to your problem in terms of standard C++.

I believe that if the function is not declared static that all calls to that
function are made via a jump table and that this is how linking/loading
is done. In essence, I have to walk my own stack and determine if
I'm in a particular function and for that I need the real address of the
function and not the address of the jump instruction in the jump table.
The debugger has to do this as well but I need to do it manually. The
reason why is long, complex, and uninteresting. I already wrote a
function in case I needed it that looks at the code address and determines
if it is a jump instruction and if so computes the real function address.
Obviously, this function is architecture dependent which is something I'd
like to avoid but I guess I can't.

 

[red floyd]

I believe that if the function is not declared static that all calls to that
function are made via a jump table and that this is how linking/loading
is done. In essence, I have to walk my own stack and determine if
I'm in a particular function and for that I need the real address of the
function and not the address of the jump instruction in the jump table.
The debugger has to do this as well but I need to do it manually. The
reason why is long, complex, and uninteresting. I already wrote a
function in case I needed it that looks at the code address and determines
if it is a jump instruction and if so computes the real function address.
Obviously, this function is architecture dependent which is something I'd
like to avoid but I guess I can't.

I assume you are talking about *member* functions. In general,
functions are not accessed by a jump table, but by direct call.
However, this is an implementation detail.

 

[Todd A. Anderson]

I assume you are talking about *member* functions. In general, functions
are not accessed by a jump table, but by direct call. However, this is an
implementation detail.

No. I'm not talking about a *member* function. At least for me, with both
VC6 and VS2005, I've noticed that sometimes when I do a call of a regular
non-member function and hit F11 (step-into) in the debugger, that rather
than
taking me directly to the called function, it takes me to a region of code
that
consists of one jump instruction after another. Think about what happens
when you call a function from file A in which it is declared extern. The
code
in the obj for file A has to include a call but to what address? You can't
use an offset from the start of the obj because the function is extern so
you
have no such offset. It seems what is done is that the compiler creates
what I called a jump table and it emits a call to an entry in this jump
table.
At load time, once the real address of the function is known, you just have
to update the jump tables to jump to the right spot rather than having to
update
every call site for each externed function.

I know about vtables and the use of indirect calls for them. What I'm
talking
about is different. The compiler still uses a direct call but it is a
direct call
of a memory location contains a jump instruction rather than the true start
of the method prolog.

 

[Thomas J. Gritzan]

No. I'm not talking about a *member* function. At least for me, with both
VC6 and VS2005, I've noticed that sometimes when I do a call of a regular
non-member function and hit F11 (step-into) in the debugger, that rather
than
taking me directly to the called function, it takes me to a region of code
that
consists of one jump instruction after another. Think about what happens
when you call a function from file A in which it is declared extern. The
code
in the obj for file A has to include a call but to what address? You can't
use an offset from the start of the obj because the function is extern so
you
have no such offset. It seems what is done is that the compiler creates
what I called a jump table and it emits a call to an entry in this jump
table.
At load time, once the real address of the function is known, you just have
to update the jump tables to jump to the right spot rather than having to
update
every call site for each externed function.

I guess this only occurs when calling a function in a DLL. The jump
tables are in the .lib files that belong to the DLL, and the DLL loader
has to update only the jump table entry in the .lib file.

But this is offtopic in this group, you have to ask in a windows
specific group for this.

Thomas

 

[Michiel.Salters]

I believe that if the function is not declared static that all calls to that
function are made via a jump table and that this is how linking/loading
is done.

One particular implementation, and one that is very often cut out by an
optimizer. I.e. don't assume that it's there just because you can see
it
in a debugger.

In essence, I have to walk my own stack and determine if
I'm in a particular function and for that I need the real address of the
function and not the address of the jump instruction in the jump table.

Won't work anyway. You're assuming contiguous functions at the very
least.
The case you encountered was a special case, but there are more
compilers
that implement functions as multiple blocks of memory. In fact, with
inlining,
the same logical code maps to multiple blocks of memory. Other cases
are
hot/cold splits where the optimizer guesses which code will be used
less
often and put that in a separate location. This can be used for e.g.
exception code, to keep it out of the CPU cache if nothing throws.

From a C++ point of view, this doesn't matter. Functions aren't objects

and can't be treated as such. You know you're in a function foo() if
you're
executing a statement of function foo (and a few other rare cases
dealing
with argument initialization)