«

Hi,

Let's say I'm in function foo.
I am trying to find the function(or return address) which called foo.

Initially, I thought I could use stack base pointer(ebp+4) to find the
return address.
However, my compiler(vs7) would go through so many function call and
ebp+4 points to somewhere in kernel32.

I can use the address of parameter and obtain the return address.
When the function call is cdecl, the return address is at
[&firstparameter -4]
I can use this but it depends on the calling convention.

I feel there must be a more general way to get a return address. (any
api?)

Any help would be appreciated.

wrote:
> Hi,
>
> Let's say I'm in function foo.
> I am trying to find the function(or return address) which called foo.
>
> Initially, I thought I could use stack base pointer(ebp+4) to find the
> return address.
> However, my compiler(vs7) would go through so many function call and
> ebp+4 points to somewhere in kernel32.
>
> I can use the address of parameter and obtain the return address.
> When the function call is cdecl, the return address is at
> [&firstparameter -4]
> I can use this but it depends on the calling convention.
>
> I feel there must be a more general way to get a return address. (any
> api?)
>
> Any help would be appreciated.
>

This is system specific.

The Austria C++ alpha available at
http://netcabletv.org/public_releases/ (warning big D/L) has a stack
trace API available for Linux and Windows - you can start there.

On May 9, 9:08 am, "all.ju...@gmail.com" <p.compass...@gmail.com>
wrote:
[snip]
> Let's say I'm in function foo.
> I am trying to find the function(or return address) which called foo.

What for? It's highly likely that if you explain what you are trying
to accomplish that you will get suggestions of way better ways
to do that.

Do you want to make the function do something different if called
from different locations? If so, you want to pass an argument that
indicates that difference, not have the function go looking in places
it shouldn't. That makes it easier to design, to debug, to maintain,
to modify, to document, and to verify.

Unless there's a *HUGE* payoff for this, my suggestion would
be not to try it, as you break all that good stuff.

If you are looking for debug information, then you want a debug util.

Near as I can tell, nobody has implemented the "comefrom"
function, except as a joke.
Socks

On May 9, 9:08 am, "all.ju...@gmail.com" <p.compass...@gmail.com>
wrote:
> Hi,
>
> Let's say I'm in function foo.
> I am trying to find the function(or return address) which called foo.

I'm puzzled by what you are trying to. Using assemly language on any
system I am aware of you could write a routine to find either:

1. The address the current function will return to; OR
2. The address of the calling function (requires walking up an
additional stack frame)

The specifics of how to do this depend entirely upon the type of
system you are running on.

"" <> ha scritto nel messaggio
news: ups.com...

> Let's say I'm in function foo.
> I am trying to find the function(or return address) which called foo.

Other than dwell into some heavy-system-specific assembly, you can also
modify the called function to include an additional parameter (or use some
global or class variable) which tells who called it; if you actually need it
in order to do something different than printing its name, you can use a
function pointer for this.


Massimo

On 9 May 2007 06:08:50 -0700 in comp.lang.c++, ""
<> wrote,
>Let's say I'm in function foo.
>I am trying to find the function(or return address) which called foo.

Any information that foo() needs to use, you should pass to foo()
as an argument. There is no such concept in c++ as "stack base
pointer(ebp+4)" and trying to find one will undoubtedly lead you to
undefined behavior.

On May 9, 3:08 pm, "all.ju...@gmail.com" <p.compass...@gmail.com>
wrote:
> Hi,
>
> Let's say I'm in function foo.
> I am trying to find the function(or return address) which called foo.
>
> Initially, I thought I could use stack base pointer(ebp+4) to find the
> return address.
> However, my compiler(vs7) would go through so many function call and
> ebp+4 points to somewhere in kernel32.
ebp+4 just points to return address, you have to dereference it in
order to obtain one.
But, generaly it depends when you obtained ebp.
ebp usually points to stack frame of previous function when entering
routine and of course esp points to return address.
so each function does this first:
push ebp; saves frame
mov ebp,esp;
sub esp, size; alloc mem for locals
now [ebp+4] points to return address,
and [ebp] to previous frame. (valid only for 32 bit)

But if omit frame pointer optimization is enabled you don;t get
frame from prev function in ebp. Actually without frame pointer
I can;t see how to do frame walk at all.

>
> I can use the address of parameter and obtain the return address.
> When the function call is cdecl, the return address is at
> [&firstparameter -4]

Use compiler instrinsics for these things, or inline assembly.
(for example gcc has intrinsics for getting frame pointer and return
address,
and it is portable to different platforms, though only level 0 frame
is promised to work and if frame optimizations are disabled)


> I can use this but it depends on the calling convention.
Calling convention and CPU and optimizations
for example what I said is not true any more for
64 bit windows (both assembly and frame set up are different).

>
> I feel there must be a more general way to get a return address. (any
> api?)

There can't be general way as code to set up stack frame
is not required to exist. This is CPU, OS and compiler
specific thing.

Greetings, Branimir.

On 9 May 2007 12:16:54 -0700, Branimir Maksimovic <>
wrote in comp.lang.c++:

> On May 9, 3:08 pm, "all.ju...@gmail.com" <p.compass...@gmail.com>
> wrote:
> > Hi,
> >
> > Let's say I'm in function foo.
> > I am trying to find the function(or return address) which called foo.
> >
> > Initially, I thought I could use stack base pointer(ebp+4) to find the
> > return address.
> > However, my compiler(vs7) would go through so many function call and
> > ebp+4 points to somewhere in kernel32.
> ebp+4 just points to return address, you have to dereference it in
> order to obtain one.

There is no such thing as "ebp+4" in the C++ language.

There is no such thing as "ebp" in a C++ program that I build for a
PowerPC 405, an ARM 920T, or a Texas Instruments 2812.

If you want to talk about "ebp", go somewhere where it is topical.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

On May 9, 3:08 pm, "all.ju...@gmail.com" <p.compass...@gmail.com>
wrote:

> Let's say I'm in function foo.
> I am trying to find the function(or return address) which called foo.

> Initially, I thought I could use stack base pointer(ebp+4) to find the
> return address.
> However, my compiler(vs7) would go through so many function call and
> ebp+4 points to somewhere in kernel32.

> I can use the address of parameter and obtain the return address.
> When the function call is cdecl, the return address is at
> [&firstparameter -4]
> I can use this but it depends on the calling convention.

> I feel there must be a more general way to get a return address. (any
> api?)

There's nothing portable. For Intel architecture, I use
something along the lines of what you do: take the address of a
local variable, then a mess of reinterpret_cast and pointer
arithmetic, going deep into the realm of undefined behavior.
For other architectures, I do other things.

Two things that might help in some cases:

-- There's usually some useful information in a jmp_buf, if you
do a setjmp. What and where are implementation defined, but
generally, will vary less than the offset relative to some
local variable.

-- G++ has two built-in functions, __builtin_return_address and
__builtin_return_address. If you're using g++, you can use
them directly. Otherwise, you might be able to generate
code using them with g++ for your platform, then study the
generated assembler, and use that as inspiration. (On the
other hand, that might "contaminate" your code with the GPL.
I'm not enough of a lawyer to say.)

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34