|
|
jacob navia wrote, On 28/03/08 23:16:
Flash Gordon wrote:
jacob navia wrote, On 28/03/08 21:39:
Kaz Kylheku wrote:
On Mar 28, 12:47 pm, Keith Thompson <ks...@xxxxxxx> wrote:
sophia <sophia.ag...@xxxxxxxxx> writes:
can any one suggest ways of implementing a backtrace function in
ANSI/
standard C as given in the following link ?
http://pramode.net/2006/09/12/getting-a-backtrace-from-running-c-code...
There's no portable way to do that in standard C.
Also, there is no nonportable way to do that in standard C, either.
:)
No, In non portable C you can do it
Sometimes. Sometimes you can't.
1) Read the frame pointer (This is the only assembly yo need)
If there is one.
Mr "Gordon":
I said this several lines below. Please read the whole message
before replying.
You said above that in non-portable C you can do it, this is not always
true.
I have the feeling that you do not red the message and try to
understand what I propose but that you jump into each sentence
trying to find out something to comment negatively on.
No, I read the entire message, and then I pointed out why your statement
that it can be done in non-portable C is not necessarily true.
2) See at what offset from the frame pointer is the pushed return
address
If there is anything to tell you other than the function prologue. Of
course the return address might not have been saved to RAM either due
to function inlining (as an optimisation) or because it did not need
to for some other reason.
The function address is always saved, or, sometimes held in a
designated register. In both cases it is at a fixed point.
On the TMS320C25 the return address could be in one of two places
depending on whether it is a leaf function or not. If it is a leaf
function the return address will have been left on the HW stack, if not
it will have been popped off the HW stack and pushed on to a stack
structure implemented in SW. How are you going to determine which is the
case? Oh, and library functions might break this rule, and certainly
functions written in assembler can.
So no, it is NOT always held in a fixed point in *real* implementations.
Obviously, if your function is *inlined* it will NOT appear
in a backtrace of the stack!
But that is "by design" isn't it?
:-)
It is still a failure to show the C call stack.
3) The value stored in the saved frame pointer position points to
the next frame.
If there is a saved frame pointer. Not all implementations use a
separate frame pointer.
See the prerequisites that I wrote below...
Had you said, "It can be done in non-portable C provided that the
following requirements are met" I might not have commented. However, you
started with an incorrect statement that it can be done in non-portable
C (which is not always true).
Here you have the next frame and the address of some point in the
calling procedure.
Maybe, if all your assumtions are true so far.
4) Read the debug information.
If there is any which there might not be.
If there is no debug information, a backtrace can still be
printed, but it is a backrace like:
0x4477ADD()
0x4477665()
etc
The address can be still useful if you have a linker map.
So why not make your statement suitable conditional?
5) Find out into which function the return address points to.
6) Is that the function "main"?
7) If not, get the next frame pointer and go to (2)
A problem if main was called recursively.
No. As I explained to Mr Heathfield, that raised the same objection,
my algorithm just stops at the first possible recursive call of main
It doesn't fail at all. It will not follow recursive calls to "main".
That is all.
Which means it is not correctly reporting the call stack, since the call
stack *includes* the recursive call to main.
Obviously, calling "main" recurisvely is very popular here.
:-)
Actually, recursive calls to main are an abominations. However they are
allowed.
---------------
This supposes that
(1) you have a frame pointer
(2) The calling function has a frame pointer
You see?
If you would have read till here, you would have saved yourself
the remarks above.
So do you accept that it is not always possible despite your claim above?
GDB is written in C, and the lcc-win debugger is
written in C. So there is OBVIOUSLY a way of doing
this in C!
No, obviously under some specific circumstances it is possible but it
is not always possible or if it is then might be more complex than you
have suggested.
Mr "Gordon"
Writing a debugger is more complex than what I outlined above.
True.
And so what?
So what indeed? We were not talking about writing a debugger.
The purpose of my algorithm description is not to provide you
with a ready made debugger implementation!
Good, since that was not the requirement.
Specially
"Read all debug information" is quite complex as an undertaking,
I can tell you.
You don't need that for the requirement. However, the requirement is not
generally possible.
Another time your suggestion breaks is if you are in a signal handler
and the signal handlers use a separate stack, which can be the case on
*nix implementations.
--
Flash Gordon
|
|