Backtrace function

[sophia]

Dear all,

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/#more-144

[dj3vande@csclub.uwaterloo.ca.invalid]

Re: Backtrace function

In article <c338370f-1230-430f-b97a-40c96008762e@s8 g2000prg.google groups.com>,
sophia <sophia.agnes@g mail.comwrote:

>Dear all,
>
>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/gettin...code/#more-144

Divine Guidance.

(Well, either that or stepping well outside what the Standard defines
to grovel through the implementation' s internal structures and finding
the information you want that way. It's probably there somewhere
(though there are cases where it can be left out without breaking
anything), so actually getting to it is a simple matter of finding out
where to look and how to interpret what you see, and then hoping it
doesn't change when you upgrade your compiler.)


dave

--
Dave Vandervies dj3vande at eskimo dot com
It's standup comedy in book form.
Which is far more entertaining than standup comedy in standup comedy form.
--Omri Schwarz in the scary devil monastery

[Richard Heathfield]

Re: Backtrace function

sophia said:

Dear all,
>
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/#more-144

When implementing functions such as backtrace(), backtrace_symbo ls(), and
backtrace_symbo ls_fd(), the best place to be sitting is the desk of the
compiler-writer. You *can* do something similar in a portable ISO C
program, but AFAIK the only way to do so is to set up a voluntary
mechanism whereby each function, on entry, pushes its name onto a
stack-like data structure provided for the purpose - and which then pops
the name off again just before returning. I've done this myself on two or
three sites, and seen it done on several more. It's not terribly difficult
- the trickiest bit is making sure that it still works even in low-memory
situations, which means either steering clear of malloc&co or getting your
memory request in nice and early.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Keith Thompson]

Re: Backtrace function

sophia <sophia.agnes@g mail.comwrites:

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/gettin...code/#more-144

There's no portable way to do that in standard C.

--
Keith Thompson (The_Other_Keit h) <kst-u@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Kaz Kylheku]

Re: Backtrace function

On Mar 28, 12:04 pm, sophia <sophia.ag...@g mail.comwrote:

Dear all,
>
can any one suggest ways of implementing a backtrace function in ANSI/
standard C as given in the following link ?

What do you think?

Where in standard C do you see a way for a function to determine even
its immediate caller, never mind that caller's caller and so on?

[Kaz Kylheku]

Re: Backtrace function

On Mar 28, 12:47 pm, Keith Thompson <ks...@mib.orgw rote:

sophia <sophia.ag...@g mail.comwrites:

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/gettin...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.

:)

[Ian Collins]

Re: Backtrace function

Flash Gordon wrote:

jacob navia wrote, On 28/03/08 21:39:
>

>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.
>

Interesting point, if your coding style is anything like mine, you will
have lots of small functions that do get inlined, leaving a pretty
useless 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.
>

x64 is a prime example, very difficult even for a debugger to work out
the callstack in optimised code.

--
Ian Collins.

[jacob navia]

Re: Backtrace function

Ian Collins wrote:

Flash Gordon wrote:

>jacob navia wrote, On 28/03/08 21:39:
>>

>>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.
>>

Interesting point, if your coding style is anything like mine, you will
have lots of small functions that do get inlined, leaving a pretty
useless 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.
>>

x64 is a prime example, very difficult even for a debugger to work out
the callstack in optimised code.
>

Yes, my debugger has still problems even with slightly
optimized code.

The first 4 arguments are not in the stack, but in
RCX,RDX,R8,and R9.

Sometimes I optimize the writing of those registers
and skip any stores. This confuses the debugger completely.

I tried to emit in the compiler, records to tell the debugger
in which registers the variable lives, but since I alias
a register to several variables at the same time if possible
(when the variables have disjoint lifetimes) that is a further
complication.

In any case for the straight backtrace there is no problem since
lcc-win ALWAYS emits a frame pointer.

I thought that for the time being, I will emit frame pointers until
I find a way of telling the debugger where the return address should
be. If not, you just can't debug optimized code!

There was recently a discussion in the gcc mailing list about the
updating of the debug information to support optimized code.

I had the impression that the poor guy that tried to do that didn't
receive much support from the compiler people, maybe because everyone
ws convinced that the task is just too difficult and would
imply a lot of modifications in the compiler.

I will try to avoid that situation. I prefer slower code but
code that can be debugged, sorry. Specially in x64, the
machines are so fast that making the code undebuggable is
just not worth the price you pay for it in undiscovered bugs!


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique

http://www.cs.virginia.edu/~lcc-win32

[Richard Heathfield]

Re: Backtrace function

jacob navia said:

Flash Gordon wrote:

>jacob navia wrote, On 28/03/08 21:39:

<snip>

>

>>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.

Well, not really, but recursive main *is* legal. It seems to me that a
non-portable solution would be free to learn main's caller (e.g. _startup,
or whatever), and probe for that instead. This would allow recursive main
calls to be backtraced properly.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Philip Potter]

Re: Backtrace function

Richard Heathfield wrote:

the point of this
discussion is not whether the program is portable but whether it is
standard. The following program is standard, non-portable C:
>
#include <stdio.h>
#include <myplatform.h >
>
int main(void)
{
printf("%d\n", mynonportablefu nction());
return 0;
}
>
whether or not the source code of mynonportablefu nction() is available.
That does not, of course, make mynonportablefu nction() topical here, but
neither is the program a priori non-standard.

I'm inclined to agree intuitively with you that this program is Standard
C. What I can't then work out is where the line between Standard C and
nonstandard C is drawn. For example, the above program exhibits
undefined behaviour (not requiring a diagnostic). The following program
also does:

int main(void)
{
int i=0;
i = i++; /* yes, our favourite topic again */
return 0;
}

but I would not describe it as Standard C. Where, then, do you propose
the line be drawn?

The closest I think I can come is "If it could conceivably be one
translation unit from a set of translation units, which when taken
together form one strictly conforming C program, then it is Standard C"

This definition allows your program but rejects mine, because there
there exists a translation unit (ie one which defines
mynonportablefu nction()) which will make your code strictly conforming.

Philip

[Richard Heathfield]

Re: Backtrace function

Philip Potter said:

Richard Heathfield wrote:

> the point of this
>discussion is not whether the program is portable but whether it is
>standard. The following program is standard, non-portable C:
>>
>#include <stdio.h>
>#include <myplatform.h >
>>
>int main(void)
>{
> printf("%d\n", mynonportablefu nction());
> return 0;
>}
>>
>whether or not the source code of mynonportablefu nction() is available.
>That does not, of course, make mynonportablefu nction() topical here, but
>neither is the program a priori non-standard.

>
I'm inclined to agree intuitively with you that this program is Standard
C. What I can't then work out is where the line between Standard C and
nonstandard C is drawn.

Ay, there's the rub! I think the answer depends on the context in which the
discussion is taking place.

For example, the above program exhibits
undefined behaviour (not requiring a diagnostic).

Right up until we provide a definition for mynonportablefu nction(), yes.

The following program also does:
>
int main(void)
{
int i=0;
i = i++; /* yes, our favourite topic again */
return 0;
}
>
but I would not describe it as Standard C. Where, then, do you propose
the line be drawn?

I don't think a line /can/ be drawn, insofar as it really depends on what
we're trying to achieve by drawing it.

The closest I think I can come is "If it could conceivably be one
translation unit from a set of translation units, which when taken
together form one strictly conforming C program, then it is Standard C"

....even if it's non-portable standard C. Yes.

>
This definition allows your program but rejects mine, because there
there exists a translation unit (ie one which defines
mynonportablefu nction()) which will make your code strictly conforming.

There *could* exist a translation unit, yes.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[CBFalconer]

Re: Backtrace function

Richard Heathfield wrote:

>

.... snip ...

>
Addressing your non sequitur, however, consider the following
code:
>
#include <stdio.h>
>
int main(void) {
printf("Hello, world.\n");
return 0;
}
>
I have used implementations that don't ship their libraries in
source form, and yet the call to printf works just fine, and I
*do* get an executable program. So your non sequitur appears to
be incorrect.

I don't think it makes sense to include the C std as a portion of
every article. The above is different, because it is calling on
standard functions, specified by the standard. Certainly functions
can be written in other languages, however there are penalties, and
the result is not portable. I maintain that writing portable C
requires writing code in C, not using non-standard functions unless
std C source is given, and a few other minor niggling points.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.


--
Posted via a free Usenet account from http://www.teranews.com

[Richard Heathfield]

Re: Backtrace function

CBFalconer said:

<snip>

Certainly functions
can be written in other languages, however there are penalties, and
the result is not portable.

Right.

I maintain that writing portable C
requires writing code in C, not using non-standard functions unless
std C source is given, and a few other minor niggling points.

Right.

So you appear to agree, now, that the code is standard, non-portable C.
Well done - you now agree with Jacob *and* me. This is quite possibly a
first in the history of comp.lang.c.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[CBFalconer]

Re: Backtrace function

Richard Heathfield wrote:

CBFalconer said:
>
<snip>
>

>Certainly functions
>can be written in other languages, however there are penalties, and
>the result is not portable.

>
Right.
>

>I maintain that writing portable C
>requires writing code in C, not using non-standard functions unless
>std C source is given, and a few other minor niggling points.

>
Right.
>
So you appear to agree, now, that the code is standard, non-portable
C. Well done - you now agree with Jacob *and* me. This is quite
possibly a first in the history of comp.lang.c.

Is that what this is all about? A fine distinction between
'standard' and 'portable'? To me, standard C is portable.
Non-portable C is non-standard. Again, to me.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

[Richard Heathfield]

Re: Backtrace function

CBFalconer said:

Richard Heathfield wrote:

<snip>

>>
>So you appear to agree, now, that the code is standard, non-portable
>C. Well done - you now agree with Jacob *and* me. This is quite
>possibly a first in the history of comp.lang.c.

>
Is that what this is all about?

If you don't know what it's all about, why are you participating in the
thread? comp.lang.c is not a write-only newsgroup.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999