Function invocation location

1

1.41421

I was wondering if it would be possible to find out, from within a
function, the file and line number where that particular function call
was invoked, bearing in mind that the function can potentially be
invoked from many different files. I guess that what I am looking for
is something similar to the __FILE__ and __LINE__ symbols, but one
level up in the function call stack.
 
K

Keith Thompson

I was wondering if it would be possible to find out, from within a
function, the file and line number where that particular function call
was invoked, bearing in mind that the function can potentially be
invoked from many different files. I guess that what I am looking for
is something similar to the __FILE__ and __LINE__ symbols, but one
level up in the function call stack.

No, there's no good portable way to do that.

You could probably do something involving passing extra arguments to
your functions, but it wouldn't be pretty.

A source level debugger should be able to show this information
interactively.

What are you trying to accomplish?
 
C

castillo.bryan

I use macros to do it



#include <stdio.h>

#define perform_action(a) _perform_action((a),__FILE__,__LINE__)
void _perform_action(int actCd, const char * file, int lineno);


void _perform_action(int actCd, const char * file, int lineno) {
printf("Called perform_action from %s:%d\n", file, lineno);
}


int main(void) {
perform_action(4);
return 0;
}
 
1

1.41421

Keith said:
No, there's no good portable way to do that.

You could probably do something involving passing extra arguments to
your functions, but it wouldn't be pretty.

A source level debugger should be able to show this information
interactively.

What are you trying to accomplish?

Pretty much what I said: To find out who is invoking a certain
function, and at what point. I am using an embedded environment, and a
source level debugger does disturb things so that what I am trying to
see is not there anymore. The only way I could think of to do it is by
means of the info above, and well-placed printf (the output of which
goes to a console accessible through a serial port).
 
C

castillo.bryan

You can also (sometimes) get stack trace information on linux with the
functions: backtrace and backtrace_symbols. I don't remember what
information you could get from the functions (if it was file, line, or
function/symbol name), but I think you could get symbol names for
functions that weren't static.
 
K

Keith Thompson

I use macros to do it

You use macros to do what? Please read
<http://cfaj.freeshell.org/google/>. Google's posting interface is
badly broken, but it can be used correctly with just a little extra
effort.
#include <stdio.h>

#define perform_action(a) _perform_action((a),__FILE__,__LINE__)
void _perform_action(int actCd, const char * file, int lineno);

Avoid identifiers with leading underscores. Many of them are reserved
for use by the implementation. Rather than memorizing or looking up
the rules for which ones are reserved in which contexts, it's best to
just avoid them altogether (unless you're using something defined for
you by the implementation).

If you want to generate an identifier from an existing one, trailing
underscores are ok.
void _perform_action(int actCd, const char * file, int lineno) {
printf("Called perform_action from %s:%d\n", file, lineno);
}


int main(void) {
perform_action(4);
return 0;
}

Otherwise, that looks reasonable. It's a lot of extra work, it only
goes up one level (going up arbitrarily many levels is going to be
interesting), and it only works for functions for which you
specifically provide the feature.

The most likely reason you'd want this information is for debugging.
In that case, a good source-level debugger should give you that
information and a lot more as well. If you want the behavior of the
function to vary depending on where it's called from, that's almost
certainly a bad idea, better implemented by just passing an extra
argument to control the behavior.

As with a lot of low-level stuff like this, the first thing you should
do is step back and decide what problem you're actually trying to
solve. It's likely that there's a better and/or more portable
solution.
 
K

Keith Thompson

Pretty much what I said: To find out who is invoking a certain
function, and at what point. I am using an embedded environment, and a
source level debugger does disturb things so that what I am trying to
see is not there anymore. The only way I could think of to do it is by
means of the info above, and well-placed printf (the output of which
goes to a console accessible through a serial port).

If a source level debugger masks the problem, it's likely that either
the debugger is broken or you're dealing with undefined behavior. You
can do what you want by changing your code, but that's also likely to
disturb things. (It's worth a try, though.)

If you know how the compiler lays out stack frames, you *might* be
able to display the return address in, say, hexadecimal, and map that
back to the point at which the function was called. This is clearly
*extremely* system-specific, so we can't really go into it here, but
it might give you what you need.
 
1

1.41421

I use macros to do it



#include <stdio.h>

#define perform_action(a) _perform_action((a),__FILE__,__LINE__)
void _perform_action(int actCd, const char * file, int lineno);


void _perform_action(int actCd, const char * file, int lineno) {
printf("Called perform_action from %s:%d\n", file, lineno);
}


int main(void) {
perform_action(4);
return 0;
}

Would this not stop working if, instead of using the name of the
function itself, one invokes it via a pointer?
 
J

jacob navia

Keith Thompson a écrit :
[snip]
If a source level debugger masks the problem, it's likely that either
the debugger is broken or you're dealing with undefined behavior.

It is impossible for a debugger to mask itself completely.
Having written a debugger for embedded systems I can tell you,
the debugger is a BIG mess that comes upon your poor program.

Impossible to do otherwise in cramped conditions, no RAM,
no MMU, etc.

That the program has "undefined behavior" is obvious, if not he
would not be trying to debug !!!
You
can do what you want by changing your code, but that's also likely to
disturb things. (It's worth a try, though.)

I agree with you in this. The printfs do CHANGE things, and even if
the impact is smaller than the impact of the debugger, they DO CHANGE
the program, as you said.
If you know how the compiler lays out stack frames, you *might* be
able to display the return address in, say, hexadecimal, and map that
back to the point at which the function was called. This is clearly
*extremely* system-specific, so we can't really go into it here, but
it might give you what you need.

That is the best solution for this problem. Find out how the
compiler lays out the stack frame (an assembly listing will do that)
and try to send the hexadecimal return address through the serial
line.

With the help of a link map, you can figure out where you were called from.


jacob
 
1

1.41421

Keith said:
If a source level debugger masks the problem, it's likely that either
the debugger is broken or you're dealing with undefined behavior. You
can do what you want by changing your code, but that's also likely to
disturb things. (It's worth a try, though.)

There are some timing considerations that the debugger interferes
with in an unavoidable way. On the other hand, a few printf statements
do not disturb such considerations significantly.
 
K

Keith Thompson

jacob navia said:
Keith Thompson a écrit :
[snip]
If a source level debugger masks the problem, it's likely that either
the debugger is broken or you're dealing with undefined behavior.

It is impossible for a debugger to mask itself completely.
Having written a debugger for embedded systems I can tell you,
the debugger is a BIG mess that comes upon your poor program.

Impossible to do otherwise in cramped conditions, no RAM,
no MMU, etc.

That the program has "undefined behavior" is obvious, if not he
would not be trying to debug !!!

Not at all. All we know is that the program has incorrect behavior.
It could be the result of unspecified behavior, system-defined
behavior, or just an incorrect algorithm. The fact that using a
source level debugger changes the behavior makes it likely that the
problem is caused by undefined behavior, but it's still not certain.
 
F

Flash Gordon

Keith Thompson wrote:

If a source level debugger masks the problem, it's likely that either
the debugger is broken or you're dealing with undefined behavior.

The arguably broken debugger is definitely one that happens in real
life. I've dealt with a processor where the only ICE and simulator both
broke the behaviour of the processor pipeline whenever the code hit a
breakpoint or when you single stepped. I considered it to be severely
broken, but there were no alternatives available.
> You
can do what you want by changing your code, but that's also likely to
disturb things. (It's worth a try, though.)

Yes, definitely worth a try.
If you know how the compiler lays out stack frames, you *might* be
able to display the return address in, say, hexadecimal, and map that
back to the point at which the function was called. This is clearly
*extremely* system-specific, so we can't really go into it here, but
it might give you what you need.

Or the compiler might have an extension to do it, but as Keith says this
is highly system specific.
 
F

Flash Gordon

jacob said:
Keith Thompson a écrit :
[snip]
If a source level debugger masks the problem, it's likely that either
the debugger is broken or you're dealing with undefined behavior.

It is impossible for a debugger to mask itself completely.

Not always the case except in terms hardware timings. Some In-Circuit
Emulators I have used, that come with high-level language debuggers, use
special versions of the chips that allow the ICE to stop the processor
dead and examine everything (including the internal registers) without
disturbing anything.
Having written a debugger for embedded systems I can tell you,
the debugger is a BIG mess that comes upon your poor program.

Not always the case.
Impossible to do otherwise in cramped conditions, no RAM,
no MMU, etc.

Not always the case, since the debugger may not even be running on the
same processor. See ICE above.
That the program has "undefined behavior" is obvious, if not he
would not be trying to debug !!!

No, it could be any kind of error, not necessarily undefined behaviour.
I agree with you in this. The printfs do CHANGE things, and even if
the impact is smaller than the impact of the debugger, they DO CHANGE
the program, as you said.

Indeed. Also, if it is an embedded system, sometimes a logic analyser is
the best tool.
That is the best solution for this problem. Find out how the
compiler lays out the stack frame (an assembly listing will do that)
and try to send the hexadecimal return address through the serial
line.

Check the documentation before reading the assembly output. There may be
extensions to help, or the documentation may tell you what the stack
layout is.
With the help of a link map, you can figure out where you were called from.

Not always that simple if there are dynamically loaded libraries, since
they might not always be loaded to the same address.
 
J

jacob navia

Flash Gordon a écrit :
jacob said:
Keith Thompson a écrit :
[snip]
If a source level debugger masks the problem, it's likely that either
the debugger is broken or you're dealing with undefined behavior.


It is impossible for a debugger to mask itself completely.


Not always the case except in terms hardware timings. Some In-Circuit
Emulators I have used, that come with high-level language debuggers, use
special versions of the chips that allow the ICE to stop the processor
dead and examine everything (including the internal registers) without
disturbing anything.

Well, that's a debugger with hardware assist. We do not all have
that luxury...

The debugger I wrote was for a chip that was designed and built around
a chip that offered 80K Ram, that could not be used for debugging,
and program memory (EPROM) that could not be altered. The compiler
would emit instructions at each line to test for a line breakpoints
array.

If the current line was found in the array, it would change
to a "server" mode that sent info to the PC debugger. HELL I can
tell you!
Not always the case.

Of course not. Maybe in the debuggers I wrote only :) Or the debugger
writers are much more lucky, benefit from hardware assist, etc.
Not always the case, since the debugger may not even be running on the
same processor. See ICE above.

If your processor doesn't have any ICE or breakpoint instruction
the debugger becomes tricky even if the real debugger runs in a PC.
No, it could be any kind of error, not necessarily undefined behaviour.

Errors that disappear when the debugger steps in are mostly UB, except
of timing constraints.
 
F

Flash Gordon

jacob said:
Flash Gordon a écrit :
jacob said:
Keith Thompson a écrit :
[snip]

If a source level debugger masks the problem, it's likely that either
the debugger is broken or you're dealing with undefined behavior.

It is impossible for a debugger to mask itself completely.

Not always the case except in terms hardware timings. Some In-Circuit
Emulators I have used, that come with high-level language debuggers,
use special versions of the chips that allow the ICE to stop the
processor dead and examine everything (including the internal
registers) without disturbing anything.

Well, that's a debugger with hardware assist. We do not all have
that luxury...

Agreed. I fully accept that sometimes debuggers have to work within the
limitations you talked about, it's just not always the case.

Anyway, this is OT here, so I think we should drop it.

If your processor doesn't have any ICE or breakpoint instruction
the debugger becomes tricky even if the real debugger runs in a PC.

You can always write a complete emulation of the hardware and run the
emulation on a PC (or other powerful computer) which, of course,
potentially gives the debugger full control since the "processor" is
then part of the debugger rather than a real piece of HW :)

I've seen it done and used such simulator debuggers, just a pittle the
ones I used were very badly written.
Errors that disappear when the debugger steps in are mostly UB, except
of timing constraints.

I've come across many real world situations where there was no undefined
behaviour, but there was a timing issue. Or, as in the code I debugged
the day before yesterday, if something external responds too slowly the
code invokes undefined behaviour, but if you step through the code the
external event happens fast enough so you don't invoke undefined
behaviour. I identified the bug by the use of valgrind and code inspection.
 
C

castillo.bryan

Would this not stop working if, instead of using the name of the
function itself, one invokes it via a pointer?


You are right. Since you can't get the address of a macro you would
have to use the address of the real function, which would mean you
would have to explicitly pass __FILE__ and __LINE__.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,755
Messages
2,569,535
Members
45,007
Latest member
obedient dusk

Latest Threads

Top