Print function name of calling function?

[dspfun]

Hi,

Is it possible to print the function name of the calling function?

For example, f1() and f2() both calls f3(), in f3() I would like to
print the name of the function calling f3() which could either be f1()
or f2().

BRs!

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

matevzb wrote:

On Feb 20, 8:26 am, "dspfun" <dsp...@hotmail .comwrote:

Hi,

Is it possible to print the function name of the calling function?

For example, f1() and f2() both calls f3(), in f3() I would like to
print the name of the function calling f3() which could either be f1()
or f2().

If I remember correctly, a C99 implementation should implement the
__func__ identifier. It's implicitly declared and equals to
static const char __func__[] = "function-name";

You are correct. However, __func__ contains the name of the current
function, not of the calling function.

[matevzb]

On Feb 20, 10:09 am, "Harald van Dijk" <true...@gmail. comwrote:

matevzb wrote:

On Feb 20, 8:26 am, "dspfun" <dsp...@hotmail .comwrote:

Hi,

Is it possible to print the function name of the calling function?

For example, f1() and f2() both calls f3(), in f3() I would like to
print the name of the function calling f3() which could either be f1()
or f2().

If I remember correctly, a C99 implementation should implement the
__func__ identifier. It's implicitly declared and equals to
static const char __func__[] = "function-name";

You are correct. However, __func__ contains the name of the current
function, not of the calling function.

Sorry, I misread the OP's question. In that case it's probably best if
the __func__ is passed to the called function.
--
WYCIWYG - what you C is what you get

[Gordon Burditt]

Is it possible to print the function name of the calling function?

>
Not portably.

For example, f1() and f2() both calls f3(), in f3() I would like to
print the name of the function calling f3() which could either be f1()
or f2().

So the caller can't rely on f3() behaving consistently?

If you need more info than you pass in the function arguments, the
obvious suggestion is to simply add some more function arguments.

In gdb it is possible to get a call trace, how can gdb get the call
trace? Does gdb use some OS-specific functions for this?

gdb uses system-specific ways to get the function's addresses, but
loads the compiler-generated debug info (including the calling
function's name) from the executable. In your own code, you cannot
even assume that your own program can read itself, let alone rely on a
specific debugging format.

It gets worse than that. Also, gdb has been known to get this
WRONG, especially if something managed to clobber the stack (if
there is one) frame.

- You cannot assume that your own program can even FIND itself. argv[0]
need not be a *file* name. Also, it's easy for malicious invokers to
fake this information. Same goes for getenv("PATH").
- Not all systems have things like /proc/curproc/file (FreeBSD) or
/proc/self/exe (Linux) which provide a symlink to the executable.
You still might not have permission to access it in any case.
- You cannot assume that you have read permission on the executable.
Execute-only permission is possible in a number of operating systems.
Plus, the higher-level directory permissions may not permit access.
- You cannot assume that you can open the executable for read while it's
running. Some operating systems give an ETXTBSY error. (More give
ETXTBSY if you try opening for *write*).
- You cannot assume that the executable has any debugging symbols in *ANY*
format, much less one that you can interpret. They may not be generated,
or they may be stripped off later for production use. Among other things,
in a large software distribution, those symbols can take up a lot of
disk space. And closed-source software distributions will probably remove
symbols to avoid giving away too much information.
- Even if the executable has debugging symbols, you may not have all the
debugging symbols you need (e.g. for libraries, static-linked or dynamic-
linked). Sometimes a library function can call YOUR function (e.g.
qsort calling a compare function).
- Finding the symbols for a dynamic-linked library can be very
system-dependent. No, you can't depend on having dynamic-linked libraries,
but neither can you depend on NOT having them.
- Even if you have all the function addresses, stack (if there is one) frame
formats and calling sequences are very system-dependent.
- The symbol associated with the function name may bear minimal resemblance
to the actual function name (C++ name-mangling, for example).

[Gordon Burditt]

Is it possible to print the function name of the calling function?

>
For example, f1() and f2() both calls f3(), in f3() I would like to
print the name of the function calling f3() which could either be f1()
or f2().

If I remember correctly, a C99 implementation should implement the
__func__ identifier. It's implicitly declared and equals to
static const char __func__[] = "function-name";

You are correct. However, __func__ contains the name of the current
function, not of the calling function.

True, but you could still use it to advantage. Define an N-argument
macro f3(), which calls f3_real() with the N arguments plus an added
one, passed as __func__. Now, the name of the calling function is
passed automatically.

[CBFalconer]

Harald van D?k wrote:

matevzb wrote:

>On Feb 20, 8:26 am, "dspfun" <dsp...@hotmail .comwrote:

>>>
Is it possible to print the function name of the calling function?

For example, f1() and f2() both calls f3(), in f3() I would like
to print the name of the function calling f3() which could either
be f1() or f2().

If I remember correctly, a C99 implementation should implement the
__func__ identifier. It's implicitly declared and equals to
static const char __func__[] = "function-name";

You are correct. However, __func__ contains the name of the current
function, not of the calling function.

Exactly. So where do you think the '__func__' should be used? The
result is a char* pointer, which you can pass wherever you think it
might be of interest.

--
<http://www.cs.auckland .ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfoc us.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

[robertwessel2]

On Feb 20, 5:51 pm, gordonb.vr...@b urditt.org (Gordon Burditt) wrote:

gdb uses system-specific ways to get the function's addresses, but
loads the compiler-generated debug info (including the calling
function's name) from the executable. In your own code, you cannot
even assume that your own program can read itself, let alone rely on a
specific debugging format.

It gets worse than that. Also, gdb has been known to get this
WRONG, especially if something managed to clobber the stack (if
there is one) frame.

While I can't speak to GDB, I've seen plenty of situations where
somewhat odd (but still valid) stack frames exist due to various sorts
of optimization, and which confuse things trying to trace "standard"
stack frames.

Inlined functions will often have that attribute.