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

[dj3vande]

In article <c3**********************************@s8g2000prg.g ooglegroups.com>,
sophia <so**********@gmail.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]

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

When implementing functions such as backtrace(), backtrace_symbols(), and
backtrace_symbols_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]

sophia <so**********@gmail.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_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Kaz Kylheku]

On Mar 28, 12:04*pm, sophia <[e-mail]:

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]

On Mar 28, 12:47*pm, Keith Thompson <[e-mail]:

sophia <[e-mail]:

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]

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]

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]

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]

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", mynonportablefunction());
return 0;
}

whether or not the source code of mynonportablefunction() is available.
That does not, of course, make mynonportablefunction() 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
mynonportablefunction()) which will make your code strictly conforming.

Philip

[Richard Heathfield]

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", mynonportablefunction());
return 0;
}

whether or not the source code of mynonportablefunction() is available.
That does not, of course, make mynonportablefunction() 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 mynonportablefunction(), 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
mynonportablefunction()) 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]

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]

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]

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]

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

[CBFalconer]

Richard Heathfield wrote:

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? A fine distinction between
'standard' and 'portable'? To me, standard C is portable.
Non-portable C is non-standard. Again, to me.

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.

I have done you the favor of correcting your quote above. Your
newsreader seems to have problems providing a complete and readable
quote.

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

[jacob navia]

Kelsey Bjarnason wrote:

A given program may or may not be standard C, but if the program uses
anything beyond the standard library - its own functions, other library
functions, what have you - the only way to determine whether it qualifies
as standard C is to examine the code.

Take the example:

x = y();

Is this standard C? Depends. Perhaps y() draws a line graph by directly
accessing the VGA hardware on a DOS machine, then returns a far pointer
to the video memory. I suspect there's no way to do this in standard C,
so to determine whether x = y(); is standard C requires examining what y
does.

The syntax may be standard C; is that sufficient to determine that the
program is, without seeing the whole program, including any additional
libraries or other modules?

By this logic the function printf is NOT standard C since
it must access stdout and put characters in it. To do this,
eventually a device driver must be called that will access the screen or
the disk or what ever output medium is concerned. This device driver
will be surely be written in some other language than standard C.

Q.E.D

To be *useful* all implementations must eventually call non-standard
functions to do input/output.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Richard Heathfield]

CBFalconer said:

Richard Heathfield wrote:

>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? A fine distinction between
'standard' and 'portable'? To me, standard C is portable.
Non-portable C is non-standard. Again, to me.

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.

I have done you the favor of correcting your quote above. Your
newsreader seems to have problems providing a complete and readable
quote.

No, my newsreader works just fine, and I quoted the part I thought
relevant. If anyone (such as yourself) feels that the quoted part is
insufficient, they can check the rest of the feed or the archives.

Having said that, the "amplified" version that you have provided does not
change the point that I have made. (Had it done so, you would have had a
case for selective quotation. As it is, all you seem to be doing is
attempting to evade the point.)

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

jacob navia wrote:

Kelsey Bjarnason wrote:

.... snip ...

>

>Take the example:

x = y();

Is this standard C? Depends. Perhaps y() draws a line graph by
directly accessing the VGA hardware on a DOS machine, then
returns a far pointer to the video memory. I suspect there's no
way to do this in standard C, so to determine whether x = y();
is standard C requires examining what y does.

The syntax may be standard C; is that sufficient to determine
that the program is, without seeing the whole program, including
any additional libraries or other modules?

By this logic the function printf is NOT standard C since it must
access stdout and put characters in it. To do this, eventually a
device driver must be called that will access the screen or the
disk or what ever output medium is concerned. This device driver
will be surely be written in some other language than standard C.

To the contrary, printf action is precisely defined in the C
standard. No unexpected action will occur, barring misuse.
However, you will have a hard time finding a description of y() in
the standard.

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