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.
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.
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.
Obviously, if your function is *inlined* it will NOT appear
in a backtrace of the stack!
But that is "by design" isn't it?
:-)
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...
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.
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.
Obviously, calling "main" recurisvely is very popular here.
:-)
---------------
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.
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?
The purpose of my algorithm description is not to provide you
with a ready made debugger implementation!
Specially
"Read all debug information" is quite complex as an undertaking,
I can tell you.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
www.cs.virginia.edu/~lcc-win32">http://www.cs.virginia.edu/~lcc-win32
|